[linux-l] linux-l Nachrichtensammlung, Band 146, Eintrag 5

Thomas Osterried thomas at osterried.de
Fr Jul 5 12:07:47 CEST 2019


Hallo,

strace ist ein gutes tool. Allerdings sollte man sich im Klaren darüber sein, daß hier auch vertrauliche Daten im Klartext stehen.

>> 25375 recvfrom(0, "USER boris\r\n", 4096, MSG_PEEK, NULL, NULL) = 12
>> 25375 read(0, "USER boris\r\n", 12)     = 12
>> 25375 getpid()                          = 25375
>> 25375 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = -1 EACCES (Permission denied)
>> 25375 getpid()                          = 25375
>> 25375 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = -1 EACCES (Permission denied)
>> 25375 write(0, "331 Please specify the password."..., 34) = 34
>> 25375 rt_sigaction(SIGALRM, {sa_handler=0x562c3bdc14e0, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f2b3be3ae50}, NULL, 8) = 0
>> 25375 alarm(900)                        = 900
>> 25375 recvfrom(0, "PASS geheim\r\n", 4096, MSG_PEEK, NULL, NULL) = 13
>> 25375 read(0, "PASS geheim\r\n", 13)    = 13
>> 

=> Nutzer boris sollte jetzt sein Passwort ändern.

>> 25374 accept(5, {sa_family=AF_INET6, sin6_port=htons(58584), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::ffff:192.168.221.119", &sin6_addr), sin6_scope_id=0}, [28]) = 6

^ für den ftp-DATA stream ging die Verbindung vom ftp-client ein, host 192.168.221.119.

>> 25374 write(3, "\1", 1)                 = 1
>> 25378 <... read resumed>"\1", 1)        = 1
>> 25374 sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[6]}], msg_controllen=20, msg_flags=0}, 0 <unfinished ...>
>> 25378 recvmsg(5,  <unfinished ...>
>> 25374 <... sendmsg resumed>)            = 1
>> 25378 <... recvmsg resumed>{msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[6]}], msg_controllen=24, msg_flags=0}, 0) = 1
>> 25374 close(6 <unfinished ...>
>> 25378 setsockopt(6, SOL_SOCKET, SO_KEEPALIVE, [1], 4 <unfinished ...>
>> 25374 <... close resumed>)              = 0
>> 25378 <... setsockopt resumed>)         = 0
>> 25374 read(3,  <unfinished ...>
>> 25378 setsockopt(6, SOL_IP, IP_TOS, [8], 4) = 0
>> 25378 rt_sigaction(SIGALRM, {sa_handler=0x562c3bdc14e0, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f2b3be3ae50}, NULL, 8) = 0
>> 25378 alarm(300)                        = 900
>> 25378 getpid()                          = 25378
>> 25378 sendto(4, "<94>Jul  4 07:16:49 vsftpd[25378"..., 129, MSG_NOSIGNAL, NULL, 0) = 129
>> 25378 write(0, "150 Here comes the directory lis"..., 39) = 39

Diese Zeile wurde erfolgreich an Deinen ftp-client übertragen, denn er schreibt "150 Here comes the directory listing.".


>> 25378 getdents64(3 <unfinished ...>)    = ?
>> 25378 +++ killed by SIGSYS +++

getdents() wird üblicherweise von vom syscall readdir() verwendet.
Der Befehl ist noch nicht beendet (unfinished), da gibt's einen kill dieses Prozesses 25378. Grund?
Der alarm timer wurde auf 300s gesetzt. Hattest Du 5min warten müssen nach der "150 Here comes .." Meldung? Ich glaube aber nicht, denn (gerade mit kleinem Prograemmchen getestet) gibt es bei Ablauf des alarm timers ein SIGALARM - in Deinem Fall war es aber SIGSYS:
Mein Testprogramm:
alarm(10)                               = 0
nanosleep({20, 0}, {10, 176732})        = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
+++ killed by SIGALRM +++


>> 25374 <... read resumed>"", 1)          = 0
>> 25374 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=25378, si_uid=1000, si_status=SIGSYS, si_utime=0, si_stime=0} ---

Das Kind ist tot.

Tja, was macht er da? Ich wollte gerade schon sagen wir sind so klug wie vorher. Sind wir aber nicht. Schauen wir doch mal bei der $suchmaschiene unseres Vertrauens nach getdents64 SIGSYS und vsftpd:

https://bugs.archlinux.org/task/62889

The seccomp sandbox feature of vsftpd prevents ftp users from getting a directory listing. In the default setting a new process is created for each FTP connection that dies from the signal SIGSYS when trying to do a directory listing.
__________________________________________________________________________________^Das ist unser Problem
___________________________________________________________________________________________^Das passiert uns auch.

Der bug reporter schreibt:
"This presumably is a bug in vsftpd because it allows the execution of the getdents syscall, but not the getdents64 syscall which is used at least on my two arch linux machines."
Na ob das so stimmt? Immerhin sehen wir einen getdents64() syscall durchgereicht in den Kernel.

Ein Versuch, ob
  "The seccomp_sandbox option of vsftpd is active in the default configuration, when disabling this (setting seccomp_sandbox=NO in the /etc/vsftpd.conf) the directory listing works as intended."
fruchtet, ist es allemal wert.

Wie immer gilt: nach dem Verändern von Konfigurationsoptionen zum Testen von Dingen, die keine Besserung brachten, gleich wieder die Änderung rückgängig machen. Wir wollen ja schließlich keinen Schweizer Käse produzieren ;)

Viel Glück,
	- Thomas




Mehr Informationen über die Mailingliste linux-l