Standardverhalten beim Empfang eines Signals ... Was bedeuten diese beruhigenden Worte? Sicher nicht das, was Sie erwartet hatten. Das Wiki sagt, dass die Standard-28-Signalhandler (es gibt andere!) Folgende sind: 2 werden ignoriert, 4 bewirken, dass der Prozess gestoppt wird, 1 wird fortgesetzt, 11 werden beendet, 10 werden mit einem Speicherauszug beendet. Das ist interessant! Die Situation ist also wie folgt: Auch wenn Ihr Programm Signale im Quellcode in keiner Weise erwähnt, verwendet es sie tatsächlich und auf sehr dramatische Weise.
Von nun an müssen wir tiefer graben. Wer kann Signale senden und an wen? Das Wiki sagt: "Ein Prozess (oder ein Shell-Benutzer) mit einer anderen effektiven UID als 0 (Superuser-UID) kann nur Signale an Prozesse mit derselben UID senden." Wenn Sie also 100 Programme ausführen, kann jedes von ihnen alle diese 100 Programme mithilfe der System-API problemlos beenden, selbst wenn alle Programme (mit Ausnahme des Killers) keine Signale in ihrem Quellcode erwähnt haben. Wenn Sie unter dem Root-Konto gearbeitet haben, spielt es keine Rolle, wer bestimmte Prozesse gestartet hat. Sie können sie dennoch problemlos beenden. Es ist natürlich möglich, die PID eines bestimmten Prozesses herauszufinden und seinen "Vertragsmord" auszuführen, aber es ist noch einfacher, jeden zu töten, der einfach nur Bride-Force-PIDs sein kann.
„Warte, warte, fahr die Pferde nicht. Sie haben erwähnt, dass Signale verarbeitet und ignoriert werden können! " - Ich höre die Stimme meines Lesers. Was wird Vicki sagen? "Für die alternative Behandlung aller Signale außer SIGKILL und SIGSTOP kann ein Prozess einen eigenen Handler zuweisen oder deren Auftreten ignorieren, indem er seine Signalmaske ändert." Wir betrachten die Standardaktionen beim Empfang dieser Signale und sehen: "Prozessabschluss", "Prozessstopp". Es stellt sich heraus, dass wir diese beiden Aktionen ausführen können, wenn das Senden von SIGKILL- und SIGSTOP-Signalen an das Opfer grundsätzlich möglich ist. "Die einzige Ausnahme ist ein Prozess mit PID 1 (Init), der das Recht hat, alle Signale, einschließlich KILL und STOP, zu ignorieren oder zu verarbeiten."Wir sind möglicherweise nicht einmal in der Lage, einen der wichtigsten Systemprozesse als Root abzutöten, aber auf gütliche Weise erfordert dies zusätzliche Forschung.
Nun, das Bild ist etwas positiver geworden, aber es ist immer noch düster. Wenn Sie einen Prozess starten, wird garantiert, dass er eine Reihe anderer Prozesse beenden und stoppen kann. Wenn eine sehr einfache Bedingung erfüllt ist, "die Entwickler des Empfangsprozesses vergessen haben, eines der vielen anderen Signale zu ignorieren oder irgendwie damit umzugehen", kann die maniac-Anwendung den Prozess mit einem Speicherauszug beenden oder den Prozess nach dem Stoppen fortsetzen. Wenn die Entwickler der empfangenden Anwendung ihre Handler an einige Signale gehängt haben, können Sie versuchen, die Funktion dieser Anwendung zu beeinträchtigen, indem Sie Signale an sie senden. Letzteres ist ein Thema für eine separate Diskussion, da aufgrund der asynchronen Ausführung von Handlern Rennen und undefiniertes Verhalten möglich sind ...
"Abstraktes Denken ist sehr cool, aber kommen wir den Einzelheiten näher", wird mir ein anspruchsvoller Leser sagen. OK, kein Problem! Jeder * nix-Benutzer ist mit einem Programm wie bash vertraut. Dieses Programm entwickelt sich seit fast 30 Jahren und bietet eine ganze Reihe von Möglichkeiten. Lassen Sie uns sie für Klarheit füllen und etwas Leckeres aus ihrer Erinnerung holen!
Ich ziehe mein Heim-Ubuntu 16.04.2 aus dem weiten Bein und führe zwei Kopien von Bash 4.3.46 darauf aus. In einem von ihnen werde ich einen hypothetischen Befehl mit geheimen Daten ausführen: export password = SECRET. Vergessen wir für eine Weile die Befehlsverlaufsdatei, in die auch das Passwort geschrieben wird. Geben Sie im selben Fenster den Befehl ps ein, um die PID dieses Prozesses zu ermitteln, z. B. 3580.
Lassen Sie uns zum zweiten Fenster gehen, ohne das erste Fenster zu schließen. Der darin enthaltene Befehl ps gibt eine weitere PID dieser Bash-Instanz an - sagen wir 5378. Aus Gründen der Klarheit senden wir ab dieser zweiten Bash ein Signal an den ersten Befehl kill -SIGFPE 3580. Ja, lieber Leser, dies ist völlig absurd: Prozess 2 sagt nichts in Bezug auf zu verarbeiten 1, dass in diesem Prozess 1 eine fehlerhafte arithmetische Operation aufgetreten ist. Das folgende Fenster wird auf dem Bildschirm angezeigt: Die
gewünschte Abnormalität trat beim Erstellen eines Speicherauszugs auf, dh Bash scheint dieses Signal nicht zu verarbeiten oder zu ignorieren. Als ich googelte, wo ich nach der Müllkippe suchen sollte, fand ich eine detaillierte Antwort ( eins , zwei). In meinem Ubuntu sieht die Situation folgendermaßen aus: Wenn eine Anwendung aus dem Standardpaket aufgrund eines anderen Signals als SIGABRT abstürzt, wird der Speicherauszug an das Apport-Programm übertragen. Dies ist nur unser Fall! Dieses Programm stellt eine Datei mit Diagnoseinformationen zusammen und zeigt das oben gezeigte Fenster an. Auf der offiziellen Website heißt es stolz: „Apport sammelt potenziell sensible Daten wie Core Dumps, Stack Traces und Protokolldateien. Sie können Passwörter, Kreditkartennummern, Seriennummern und anderes privates Material enthalten. " Nun, ich frage mich, wo wir diese Datei haben. Ja, /var/crash/_bin_bash.1000.crash. Lassen Sie uns den Inhalt in den Ordner somedir ziehen: apport-unpack /var/crash/_bin_bash.1000.crash somedir. Zusätzlich zu verschiedenen uninteressanten Kleinigkeiten wird es einen begehrten Speicherauszug namens CoreDump geben.
Hier ist es, der Moment der Wahrheit! Lassen Sie uns diese Datei nach der Passwortzeichenfolge durchsuchen und sehen, was uns als Antwort interessant macht. Strings CoreDump Befehl | Das grep-Passwort erinnert den vergesslichen Hacker daran, dass das Passwort SECRET ist. Wunderbar!
Ich habe dasselbe mit meinem bevorzugten Texteditor gedit gemacht, indem ich angefangen habe, den Puffer einzugeben und ihn dann aus dem Speicherauszug zu lesen. Keine Probleme! In diesem Moment flüsterte Vicki ihr warnend ins Ohr: "Manchmal (zum Beispiel für Programme, die im Auftrag des Superusers ausgeführt werden) wird aus Sicherheitsgründen kein Speicherauszug erstellt." Soooo, lass uns nachsehen ... Beim Empfang eines Signals von der Root-Bash stürzte die zweite Root-Bash mit der Erstellung eines Speicherauszugs ab, aber aufgrund der Berechtigungen (-rw-r ----- mit dem Eigentümer von root) ist es nicht mehr so einfach, sie zu lesen wie die vorherigen im Besitz meines Benutzerkontos. Wenn es dem hypothetischen Killerprogramm gelungen ist, ein Signal von der UID des Superusers zu senden, kann es einen solchen Dump berühren.
Der akribische Leser kann bemerken: "Es war sehr einfach für Sie, die Daten zu finden, nach denen Sie im Müllmeer gesucht haben." Es ist wahr, aber ich bin mir sicher: Wenn Sie wissen, welche Art von Fisch Sie fangen möchten und wo er schwimmt, sollte es fast immer realistisch sein, ihn in den Müllnetzen zu finden. Zum Beispiel stört es niemanden, ein Paket mit Debugging-Informationen für ein abgestürztes Programm herunterzuladen und den Inhalt der Variablen, an denen Sie an GDB interessiert sind, durch Post-Mortem-Debugging herauszufinden.
All dies mag ziemlich harmlos aussehen, ist es aber nicht. Alle von mir beschriebenen Aktionen können problemlos von einem Programm oder Skript ausgeführt werden, das im Benutzermodus ausgeführt wird, ganz zu schweigen von einer privilegierteren Zugriffsebene. Das Fazit ist, dass eine böswillige ausführbare Sache leicht Programme nach rechts und links hacken und oft auch ihren gesamten Speicher frei lesen kann. Hier sind die Signale und Fehlerberichte! Ich bin sicher, dass auf anderen * nix-Plattformen und mit anderen Empfängerprogrammen die Situation ähnlich ist, aber ich werde es natürlich nicht überprüfen.
Der Einwand kann auftreten: Die Malware kann einfach die Debugging-Tools verwenden, um interessante Daten aus der Anwendung abzurufen. Das ist tatsächlich so. Warum ist dieser Beitrag dann? Mein Punkt ist folgender: Das erste, was mir einfällt, wenn ich versuche, Datendiebstahl von Anwendungen zu stoppen, sind die Einschränkungen bei Debugging-Tools. Sicherlich nutzen Antiviren-Tools in erster Linie die Verwendung von ptrace () - dies ist ein sehr verdächtiges Ereignis. Signale sind eine ganz andere Sache. Ein Prozess sendet einem anderen ein Standardsignal - na und? Auf den ersten Blick ist dies ein ganz normales Ereignis. Wie wir bereits gesehen haben, kann dies zu einer abnormalen Beendigung der Anwendung führen und in einem Ordner einen Core-Dump erstellen, aus dem versucht werden kann, ihn abzurufen.
Als ich versuchte, die Anmeldeseite von vk.com zu öffnen und Firefox mit demselben schwerwiegenden Signal zu sichern, stürzte es ab, rief aber seinen Dump-Handler auf. Dumps im kniffligen Minidump-Format werden unter ~ / .mozilla / Firefox / Crash Reports / {ausstehend oder eingereicht} gespeichert und müssen weiter untersucht werden. Folgendes erfahren Sie, wenn Sie im Einstellungsfenster neben dem Häkchen auf "Weitere Informationen " klicken (der folgende Text wurde unter www.mozilla.org/ru/privacy/firefox/#crash-reporter verwendet ):
« Mozilla Firefox. , Firefox, , URL- , . , , . crash-stats.mozilla.com. . .»Es gibt selten etwas wirklich Leckeres in URLs, aber ob es Passwörter oder Cookies in Dumps gibt, ist eine gute Frage!
In diesem mysteriösen und faszinierenden Sinne werde ich enden. Ich habe ein Signal erhalten, das ich vergessen habe, explizit zu verarbeiten.
PS Ich habe ein einfaches Programm mit einem solchen Signalhandler SIGUSR1 geschrieben: Drucke die Zeichenfolge "1" auf dem Bildschirm, betrete eine Endlosschleife. Ich hatte gehofft, dass, wenn Sie das SIGUSR1-Signal mehrmals an dieses Programm senden, der Handler viele Male aufgerufen wird, was zu einem Stapelüberlauf führt. Leider wurde der Handler nur einmal angerufen. Okay, schreiben wir einen ähnlichen Handler für das SIGUSR2-Signal und senden zwei verschiedene Signale in der Hoffnung, dass dies das Opfer entleert ... Leider hat es auch nicht geholfen: Jeder Handler wurde nur einmal aufgerufen. Übergelaufen, übergelaufen, aber nicht übergelaufen!
PS 2. In der Windows-Welt gibt es eine Art von Signalen - Nachrichten, die an Windows gesendet werden können . Es ist sehr wahrscheinlich, dass sie auch für Spaß und Gewinn verwendet werden können!
Das Original wurde auf meinem Blog 05/05/17 veröffentlicht.