proftpd nach update nicht mehr startbar

[Riseofdead]

Hallo

Da ich gesehen habe das die Version 1.3.4a aus dem Jahr 2011 ist habe ich versucht eine neuere Version zu installieren. Ich bin so vorgegangen

mit wget ftp://ftp.proftpd.org/distrib/source/proftpd-1.3.5.tar.gz die Quelldaten downgeloadet

mit ./configure die Dateien konfiguriert

dann mit make install das ganze Installiert. Fehler oder so kam keiner. Trotzdem kann ich den ftpserver nicht starten. ich habs mit service proftpd start versucht. Das komische ist das er kein "unrecognized service" ausgab sondern einfach nichts. Das komische ist das ich problemlos mit apt-get install proftpd die alte Version wieder installieren kann.

Hab ich beim kompilieren irgendwas vergessen?

PS: Kann sein das die Version aus den Debian Repos gut ist aber ich mag mal wissen wie man so ein Programm erfolgreich kompiliert und dann auch lauffähig machen. Und ich denke mal es schadet nicht wenn ich 1.3.5 installiert habe. Neben dem Interesse die neueste Version von proftpd zu haben geht es bei mir deshalb auch um den Lernerfolg da ich später einmal Arch Linux verwenden möchte.

 

[HominiLupus]

Da ist gar nix komisch, du hast in /usr/local/bin hin installiert und via apt installierte Pakete und selber kompiliert haben auch nix miteinander zu tun. Starte proftpd von dort ohne die init.d Datei.

Wieso hat deine Distro noch Pakete von 2011?

PS: bitte bleibe bei einer kuratierten Distro.

PPS: einfach via make install zu installieren ist immer ne blöde Idee, egal welche Distro. Mindestens man checkinstall oder sowas mal ansehen.

 

[Riseofdead]

ok es scheint als wär das Programm installiert. Jedoch mit einer eigenen proftpd.conf Datei. Ich hab jetzt die configuration vom alten proftpd nach /usr/etc/proftpd.conf kopiert. Jedoch funktioniert der service Befehl noch nicht. Es wird einfach nichts ausgegeben.

Ich brauch unbedingt die config vom alten Server da der neue Server verrückt spielt. Da bin ich nicht eingesperrt sondern kann bis zum Rootverzeichnis zurückspringen usw.

Ergänzung (30. September 2014)

hmm im Ordner /usr/local/bin sind jetzt nur noch 4 Ordner drin.

st0aBaZH st2zS8pN stgfck7I stqQ8GWF

Wieso haben die so komische Namen?

Ergänzung (30. September 2014)

ok hab /usr/local/bin/* einfach mal gelöscht und alles neugestartet. Fange jetzt von vorne an. ./configure funktioniert. checkinstall findet er nicht. Wird unter Debian wahrscheinlich nicht funktionieren. dann hab ich make install eingegeben. Jetzt habe ich unter /usr/local/sbin die proftpd Datei gefunden. mit proftpd stop kommt nur ein 2014-09-30 16:56:42,560 proftpd[12590]: fatal: unknown parameter: 'stop'

Wie kann ich dem Programm beibringen das er meine config nehmen MUSS und wie man den Dienst Startet/Stoppt/Status abfragt?

Ergänzung (30. September 2014)

ok hab jetzt rausgefunden das man checkinstall nachinstallieren kann. Das Programm hat mir jetzt eine schöne .deb Datei gemacht und installiert. Jetzt findet aber service proftpd start das Programm nicht. Also ein unrecognized service

 

[HominiLupus]

/usr/etc/proftpd.conf

Den Pfad sollte es nicht geben und wenn du den angelegt hast ist das totaler Blödsinn.
Alles was du hier machst ist Käse ehrlich gesagt.

http://ircbots.debian.net/factoids/factoid.php?key=ssb

PS: service start <daemon> funktioniert nur wenn es ein /etc/init.d Skript gibt.

 

[Riseofdead]

keine Ahnung der hat sich von selbst angelegt inklusive standard proftpd.conf Datei.

Ich habs jetzt mal mit ./configure --prefix=/usr/bin probiert. Da konnte checkinstall kein Temporäres Verzeichnis anlegen.

Ohne Prefix kann er /var/log nicht staten. Nachdem ich mal die manpage durchgeschaut hab las sich das so als müsste man C oder C++ können. Es hat auf jedenfall irgendwas mit int zu tun und das hat mit irgendeiner Programmsprache zu tun. Nachdem gcc was mit C zu tun hat muss es sich auch um C handeln. Ich glaub das man ohne C(++) Kenntnisse nicht kompilieren kann. Ist wohl doch schwerer als gedacht.

Naja muss ich halt wieder Proftpd 1.3.4a vom 11. November 2011 aus den debian repos benutzen. Gibt anscheinend zwar einen exploit

ZDI-CAN-925: ProFTPD TELNET_IAC Remote Code Execution Vulnerability

-- CVSS ----------------------------------------------------------------
10, (AV:N/AC:L/Au:N/C:C/I:C/A:C)

-- ABSTRACT ------------------------------------------------------------

TippingPoint has identified a vulnerability affecting the following 
products:

    ProFTPD FTP Server

-- VULNERABILITY DETAILS -----------------------------------------------

This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of ProFTPD. Authentication is not required to
exploit this vulnerability. 

The flaw exists within the proftpd server component which listens by
default on TCP port 21. When reading user input if a TELNET_IAC escape
sequence is encountered the process miscalculates a buffer length
counter value allowing a user controlled copy of data to a stack buffer.
 A remote attacker can exploit this vulnerability to execute arbitrary
code under the context of the proftpd process.

Tested on proftpd-1.3.3a.
[Switching to process 31268]
0x0806d498 in pr_netio_telnet_gets (buf=0xbf979ffc 'A' <repeats 200
times>..., buflen=4294963202, in_nstrm=0x97d77e4, out_nstrm=0x97d79f4)
at netio.c:1103
1103          *bp++ = cp;

FTP commands are read by function pr_cmd_read() of file
src/main.c (line 566).

The function pr_cmd_read() uses a local buffer (line 568):
  char buf[PR_DEFAULT_CMD_BUFSZ+1] = {'\0'};

At line 582, pr_cmd_read() calls pr_netio_telnet_gets():
  if (pr_netio_telnet_gets(buf, sizeof(buf)-1, [...]

The second parameter of pr_netio_telnet_gets() is "sizeof(buf)-1",
so its value is :
  sizeof(buf)-1 =
  (PR_DEFAULT_CMD_BUFSZ+1)-1 =
  PR_DEFAULT_CMD_BUFSZ =          [defined in src/main.c]
  PR_TUNABLE_PATH_MAX + 7 =       [defined in include/options.h]
  MAXPATHLEN + 7 =                [on Linux, MAXPATHLEN==4096]
  4096 + 7 =
  4103

The function pr_netio_telnet_gets() is defined in src/netio.c
(line 991):
  pr_netio_telnet_gets(char *buf, size_t buflen, [...]

We have buflen==4103. It is first decremented, and then
each read character decrements it. This is inside a loop
which stops when buflen==0, or when a '\n' character
is found (line 1039).

However, on line 1073, there is:
  buflen--;
So, buflen can be decremented by TWO inside the loop. This
case occurs because the function processes TELNET_IAC
escape characters followed by a TELNET_xyz character.

So, successive buflen values can be :
  4103
  4102
  ...
  3
  2
  1 (here we manage to decrement by TWO, by putting
     a TELNET_IAC character at this location)
  -1
  -2
  ...
So, the loop never stops because buflen is never zero.
The loop will only stop when a '\n' character is found
(line 1039).

So, every character between the TELNET_IAC and the
'\n' will overflow the stack buffer. This is a classical
stack overflow.


-- CREDIT --------------------------------------------------------------

This vulnerability was discovered by:
    * Anonymous

aber auf 1.3.5 kann man wohl nicht so leicht updaten.

 

[HominiLupus]

Den Exploit gibt es in Version 1.3.3a und wurde gefixt in Upstream 1.3.3c. Liest du überhaupt selber was du hier pastest? Dein Debian hat 1.3.4

*sigh*

Zudem werden in Debian Stable immer alle Security Updates gemacht ohne daß sich damit die Versionsnummer ändert: wenn nötig wird der Patch backported.
https://www.debian.org/security/