Ich führe einen Software-Daemon aus, der für bestimmte Aktionen die Eingabe einer Passphrase erfordert, um einige Funktionen freizuschalten, die beispielsweise so aussehen:

$ darkcoind masternode start <mypassphrase>

Jetzt habe ich einige Sicherheitsbedenken auf meinem headless Debian-Server.

Wann immer ich zum Beispiel meine Bash-Historie mit durchsuche, Ctrl+Rkann ich dieses superstarke Passwort sehen. Jetzt stelle ich mir vor, mein Server ist kompromittiert und ein Eindringling hat Shell-Zugriff und kann einfach Ctrl+Rmeine Passphrase im Verlauf finden.

Gibt es eine Möglichkeit das Passwort eingeben , ohne es in der Bash Geschichte gezeigt werden, ps, /procoder anderswo?

Update 1 : Wenn Sie dem Dämon kein Kennwort übergeben, wird ein Fehler ausgegeben. Dies ist keine Option.

Update 2 : Sagen Sie mir nicht, dass ich die Software oder andere hilfreiche Hinweise wie das Aufhängen der Entwickler löschen soll. Ich weiß, dass dies kein Best-Practice-Beispiel ist, aber diese Software basiert auf Bitcoin und alle Bitcoin-basierten Clients sind eine Art von JSON-RPC-Server, der diese Befehle abhört. Ein bekanntes Sicherheitsproblem wird noch diskutiert ( a , b , c ) .

Update 3 : Der Daemon ist bereits gestartet und wird mit dem Befehl ausgeführt

$ darkcoind -daemon

Dabei pswird nur der Startbefehl angezeigt.

$ ps aux | grep darkcoin
user     12337  0.0  0.0  10916  1084 pts/4    S+   09:19   0:00 grep darkcoin
user     21626  0.6  0.3 1849716 130292 ?      SLl  May02   6:48 darkcoind -daemon

Das Übergeben der Befehle mit der Passphrase wird daher in psoder überhaupt nicht angezeigt /proc.

$ darkcoind masternode start <mypassphrase>
$ ps aux | grep darkcoin
user     12929  0.0  0.0  10916  1088 pts/4    S+   09:23   0:00 grep darkcoin
user     21626  0.6  0.3 1849716 130292 ?      SLl  May02   6:49 darkcoind -daemon

Dies lässt die Frage offen, wo die Geschichte auftaucht. Nur in .bash_history?

Eigentlich sollte dies in der Anwendung selbst behoben werden. Und solche Anwendungen sollten Open Source sein, so dass das Beheben des Problems in der App selbst eine Option sein sollte. Eine sicherheitsrelevante Anwendung, die solche Fehler macht, kann auch andere Fehler machen, daher würde ich ihr nicht vertrauen.

Einfacher Interposer

Aber Sie haben nach einem anderen Weg gefragt, also ist hier einer:

#define _GNU_SOURCE
#include <dlfcn.h>

int __libc_start_main(
    int (*main) (int, char * *, char * *),
    int argc, char * * ubp_av,
    void (*init) (void),
    void (*fini) (void),
    void (*rtld_fini) (void),
    void (* stack_end)
  )
{
  int (*next)(
    int (*main) (int, char * *, char * *),
    int argc, char * * ubp_av,
    void (*init) (void),
    void (*fini) (void),
    void (*rtld_fini) (void),
    void (* stack_end)
  ) = dlsym(RTLD_NEXT, "__libc_start_main");
  ubp_av[argc - 1] = "secret password";
  return next(main, argc, ubp_av, init, fini, rtld_fini, stack_end);
}

Kompilieren Sie dies mit

gcc -O2 -fPIC -shared -o injectpassword.so injectpassword.c -ldl

dann starte deinen Prozess mit

LD_PRELOAD=$PWD/injectpassword.so darkcoind masternode start fakepasshrase

Die Interposer-Bibliothek führt diesen Code aus, bevor die mainFunktion aus Ihrer Anwendung ausgeführt wird. Es ersetzt das letzte Befehlszeilenargument durch das tatsächliche Kennwort im Aufruf von main. Die Befehlszeile, wie sie in /proc/*/cmdline(und daher von Tools wie ps) gedruckt wird, enthält jedoch weiterhin das falsche Argument. Natürlich müssten Sie den Quellcode und die Bibliothek, die Sie daraus kompilieren, nur für sich selbst lesbar machen, um am besten in einem chmod 0700Verzeichnis zu arbeiten. Und da das Passwort nicht Teil des Befehlsaufrufs ist, ist auch Ihr Bash-Verlauf sicher.

Fortgeschrittener Interposer

Wenn Sie etwas ausführlicheres tun möchten, sollten Sie berücksichtigen, dass dies __libc_start_mainausgeführt wird, bevor die Laufzeitbibliothek ordnungsgemäß initialisiert wurde. Daher würde ich empfehlen, Funktionsaufrufe zu vermeiden, sofern sie nicht unbedingt erforderlich sind. Wenn Sie Funktionen nach Herzenslust aufrufen möchten, stellen Sie sicher, dass Sie dies unmittelbar vor dem Aufruf tun main, nachdem die gesamte Initialisierung abgeschlossen ist. Für das folgende Beispiel muss ich danken Grubermensch der darauf hinweist, wie ein Passwort als Kommandozeilen - Argument übergeben zu verbergen , das gebracht , getpassum meine Aufmerksamkeit.

#define _GNU_SOURCE
#include <dlfcn.h>
#include <unistd.h>

static int (*real_main) (int, char * *, char * *);

static int my_main(int argc, char * * argv, char * * env) {
  char *pass = getpass(argv[argc - 1]);
  if (pass == NULL) return 1;
  argv[argc - 1] = pass;
  return real_main(argc, argv, env);
}

int __libc_start_main(
    int (*main) (int, char * *, char * *),
    int argc, char * * ubp_av,
    void (*init) (void),
    void (*fini) (void),
    void (*rtld_fini) (void),
    void (* stack_end)
  )
{
  int (*next)(
    int (*main) (int, char * *, char * *),
    int argc, char * * ubp_av,
    void (*init) (void),
    void (*fini) (void),
    void (*rtld_fini) (void),
    void (* stack_end)
  ) = dlsym(RTLD_NEXT, "__libc_start_main");
  real_main = main;
  return next(my_main, argc, ubp_av, init, fini, rtld_fini, stack_end);
}

Dadurch werden Sie zur Eingabe des Kennworts aufgefordert, sodass Sie die Interposer-Bibliothek nicht mehr geheim halten müssen. Das Platzhalterargument wird als Kennworteingabeaufforderung wiederverwendet. Rufen Sie dies also wie folgt auf

LD_PRELOAD=$PWD/injectpassword.so darkcoind masternode start "Password: "

Eine andere Alternative würde das Passwort aus einem Dateideskriptor (wie z. B. gpg --passphrase-fd) oder aus x11-ssh-askpassoder was auch immer lesen .

Es ist nicht nur die Geschichte. Es wird auch in der ps- Ausgabe angezeigt .

Wer diese Software geschrieben hat, sollte aufgehängt, gezeichnet und geviertelt werden. Es ist ein absolutes NEIN, unabhängig von der verwendeten Software ein Kennwort in der Befehlszeile eingeben zu müssen.
Für einen Daemon-Prozess ist es sogar noch unverzeihlicher ...

Außer rm -f auf der Software selbst kenne ich keine Lösung dafür. Ganz ehrlich: Finden Sie andere Software, um die Arbeit zu erledigen. Verwenden Sie keinen solchen Müll.

Dadurch wird die psAusgabe gelöscht.

SEHR BEACHTEN : Dies könnte die Anwendung beschädigen . Sie werden gebührend gewarnt, dass hier Drachen sind.

• Fremde Prozesse sollten nicht in einem Prozessspeicher herumspielen.
• Wenn der Prozess für das Kennwort auf dieser Region beruht, können Sie Ihre Anwendung brechen.
• Andernfalls können alle in diesem Prozess vorhandenen Arbeitsdaten beschädigt werden.
• Dies ist ein verrückter Hack.

Jetzt werden Sie ordnungsgemäß über diese ernsten Warnungen informiert. Dadurch wird die in angezeigte Ausgabe gelöscht ps. Es löscht weder Ihren Verlauf noch den Bash-Job-Verlauf (z. B. Ausführen des Prozesses wie myprocess myargs &). Aber psdie Argumente werden nicht mehr angezeigt.

#!/usr/bin/python
import os, sys
import re

PAGESIZE=4096

if __name__ == "__main__":
  if len(sys.argv) < 2:
    sys.stderr.write("Must provide a pid\n")
    sys.exit(1)

  pid = sys.argv[1]

  try:
    cmdline = open("/proc/{0}/cmdline".format(pid)).read(8192)

    ## On linux, at least, argv is located in the stack. This is likely o/s
    ## independent.
    ## Open the maps file and obtain the stack address.
    maps = open("/proc/{0}/maps".format(pid)).read(65536)
    m = re.search('([0-9a-f]+)-([0-9a-f]+)\s+rw.+\[stack\]\n', maps)
    if not m:
      sys.stderr.write("Could not find stack in process\n");
      sys.exit(1)

    start = int("0x"+m.group(1), 0)
    end = int("0x"+m.group(2), 0)

    ## Open the mem file
    mem = open('/proc/{0}/mem'.format(pid), 'r+')
    ## As the stack grows downwards, start at the end. It is expected
    ## that the value we are looking for will be at the top of the stack
    ## somewhere
    ## Seek to the end of the stack minus a couple of pages.
    mem.seek(end-(2*PAGESIZE))

    ## Read this buffer to the end of the stack
    stackportion = mem.read(8192)
    ## look for a string matching cmdline. This is pretty dangerous.
    ## HERE BE DRAGONS
    m = re.search(cmdline, stackportion)
    if not m:
      ## cause this is an example dont try to search exhaustively, just give up
      sys.stderr.write("Could not find command line in the stack. Giving up.")
      sys.exit(1)

    ## Else, we got a hit. Rewind our file descriptor, plus where we found the first argument.
    mem.seek(end-(2*PAGESIZE)+m.start())
    ## Additionally, we'll keep arg0, as thats the program name.
    arg0len = len(cmdline.split("\x00")[0]) + 1
    mem.seek(arg0len, 1)

    ## lastly overwrite the remaining region with nulls.
    writeover = "\x00" * (len(cmdline)-arg0len)
    mem.write(writeover)

    ## cleanup
    mem.close()

  except OSError, IOError:
    sys.stderr.write("Cannot find pid\n")
    sys.exit(1)

Rufen Sie das Programm auf, indem Sie chmod +xes speichern . Dann mache ./whatever <pidoftarget> Wenn dies funktioniert, wird keine Ausgabe erzeugt. Wenn es fehlschlägt, wird es sich über etwas beschweren und aufhören.

Können Sie das Argument aus einer Datei übergeben, auf die nur root oder der gewünschte Benutzer zugreifen kann?

Es ist ein RIESIGES Nein-Nein, Kennwörter in die Konsole einzugeben, aber die letzte Möglichkeit ... Beginnen Sie Ihre Zeile mit einem Leerzeichen, damit es nicht im Verlauf erscheint.

Vielleicht funktioniert das (?):

darkcoind masternode start `cat password.txt`

Wenn Ihr darkcoindBefehl das Kennwort als Befehlszeilenargument erwartet, wird es leider durch Dienstprogramme wie verfügbar gemacht ps. Die einzige wirkliche Lösung besteht darin , die Entwickler zu schulen .

Während die psEnthüllung unvermeidbar sein kann, können Sie zumindest verhindern, dass das Kennwort in die Shell-Verlaufsdatei geschrieben wird.

$ xargs darkcoind masternode start

password⏎

CtrlD

In der Verlaufsdatei sollte nur xargs darkcoind masternode startdas Kennwort und nicht das Kennwort aufgezeichnet werden.

Sehen Sie sich, wie bereits erwähnt, Ihr Shell-Verlaufssteuerelement an, um die Informationen vor dem Verlauf zu verbergen.

Aber eine Sache, die noch niemand angedeutet zu haben scheint, ist, /procmit dem hidepidParameter zu mounten . Versuchen Sie, Ihre /procZeile so /etc/fstabzu ändern hidepid, dass sie Folgendes enthält:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults,hidepid=2        0       0

Sie können das Kennwort aus dem Shell-Verlauf entfernen, indem Sie den Befehl über einen neuen Shell-Prozess ausführen, den Sie dann sofort beenden. Zum Beispiel:

bash$ sh
sh$ darkcoind masternode start 'correct horse battery staple'
sh$ exit
bash$

Stellen Sie sicher, dass shkonfiguriert ist, dass der Verlauf nicht in einer Datei gespeichert wird.

Natürlich werden die anderen Probleme, wie das Kennwort, das in angezeigt wird, dadurch nicht behoben ps. Es gibt meines Erachtens Möglichkeiten, vor denen das darkcoindProgramm selbst die Informationen verbirgt ps, aber dies verkürzt nur das Fenster der Sicherheitsanfälligkeit.

Für Bitcoin lautet die offizielle Antwort des Entwicklers, den mitgelieferten Python-Wrapper in contrib/bitrpc/bitrpc.py( github ) zu verwenden:

Sie werden auf sichere Weise nach einem Kennwort gefragt, wenn Sie beispielsweise den Befehl verwenden walletpassphrase. Es ist nicht geplant, interaktive Funktionen hinzuzufügen bitcoin-cli.

und:

bitcoin-cli bleibt unverändert und erhält keine interaktive Funktionalität.

Quelle: # 2318

Brieftasche freischalten:

$ python bitrpc.py walletpassphrase

Passwort ändern:

$ python bitrpc.py walletpassphrasechange

https://github.com/bitcoin/bitcoin/tree/master/contrib/bitrpc

Für darkcoin funktioniert es wie folgt:

https://github.com/darkcoin/darkcoin/tree/master/contrib/bitrpc