netkit-telnetd elavulta magát

 ( NevemTeve | 2015. október 14., szerda - 16:58 )

Nem lehet forrásból fordítani (ezt már abból is ki lehet találni, hogy C++ is van benne), marad a Debian, emlékeztetőül magamnak:

cd /usr/local/src
tar xfzv depo/netkit-telnet_0.17.orig.tar.gz
zcat depo/netkit-telnet_0.17-36.diff.gz | \
patch -p0 2>&1 | tee patch.log

Szerk: na jó, oké, így sem fordul, dehát mi tökéletes ebben a fájó életben?!

Szerk: a CPPFLAGS (és benne a -D_XOPEN_SOURCE) nem jutott el a Makefile-ig; az ilyenkor szokásos elegáns megoldás:

export CFLAGS="$CFLAGS $CPPFLAGS"
export CXXFLAGS="$CXXFLAGS $CPPFLAGS"

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

És most átmegyünk haxorba:

a telnetd/state.c:1374-ben az 'insecure' üzemmódot választjuk, abban a hiú reményben, hogy így több environment variable-t tudunk a kliensből bejuttatni a szerverbe. (Például a TZ jut hirtelen az eszembe: elképzelhető, hogy a kliens-program jobban tudja, hogy a felhasználó milyen időzónában van, mint a szerver. Vagy itt van a LC_CTYPE)

Szerk: és íme, .telnetrc-ből kiolvasva:

telnet localhost
...
echo $POGACSA
KRUMPLIS

Ájulat.

Ugyan a Makefile kevesbe hasznos szamodra, mivel NetBSD-hez irodott, de a forras elso par ranezesre OS-fuggetlen: http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/libexec/telnetd/
--
Blog | @hron84
Üzemeltető macik

Hát ez legalább újabb, és ebben kicsit engedékenyebb az 'envvarok' függvény...

Még az a kérdés is felmerült zavart kis agyamban, hogy milyen gondot is okozhatnak ezel a változók?
No nézzük:
1. a telnetd root-ként fut
2. és fork+exec-kel indítja a /bin/login-t
3. a /bin/login működésést esetleg környezeti változókkal befolyásolni lehet
4. vagy az általa használt libc működését (_MALLOC_CHECK pl)
5. vagy már a /bin/login betöltését manipulálni lehet LD_*, LIBPATH stb változókkal

Na jó, akkor viszont azt mondja meg valaki, hogy miért nem a sikeres login után állítjuk be a derék változókat, miért a telnetd csinálja a setenv-et.

(Interrupt: meg kellene nézni, hogy ezeket a setenv-et még a fork előtt csinálja? És ha előtte, akkor van unsetenv is? Vagy csak úgy halmozódnak a telnetd-ben a változók? Vagy, mindegy, hiszen rendszerint úgyis az inetd/tcpd indítja a telnetd-t?)

Mondjuk ehhez olyan login kell, ami elfogad változókat a parancssora végén:
login -p projects FOO_VAR=BAR_VALUE

Szerintem azert nem a /bin/login utan inicializaljuk fel a kornyezeti valtozokat, mert a telnetd ott mar nem kap kontrollt, ugyanis szvsz nem o inditja a parasztnak a shellt, hanem a login. Marpedig ez esetben a loginnak kell tudnia, hogy milyen enveket kell orokoltetni, nem tud visszakerdezni a telnetd fele, hogy most akkor leccilecci, mondd mar meg, mi merre vagyon, nincs erre protokollja. A shell pedig konkretan leszarja, o elindul azzal a keszlettel, amit a logintol kap, bekalkulal meg par dolgot a .profile meg az /etc/profile alapjan, es csok.
--
Blog | @hron84
Üzemeltető macik

Stimmel, erre vonatkozik az utolsó bekezdés: a login (legalábbis egyes verziók), átvesznek env-változókat a parancssor végén

De ez miben jobb, mintha a telnet rakna ossze forkolas elott az env. valtozokat?
--
Blog | @hron84
Üzemeltető macik

Ezt már leírtam fentebb: http://hup.hu/node/143270&comments_per_page=9999#comment-1916559
lásd az 1-5 pontokat

Ja, I see. Hat, erdekes kerdes, a LD_LIBRARY_PATH csak akkor jatszik, ha a /bin/login nem statikus binaris, a trukosebb inkabb az LD_PRELOAD, de ezeket a telnetd szintjen lehetne filterezni.
--
Blog | @hron84
Üzemeltető macik

Nem könnyű felelősséget vállalni az összes létező és majdan születendő unix-szerű rendszer környezeti változóiért;)
Amit belinkeltél, abban pl. ezeket szűrik ki:

	if (strcmp(varp, "TERMCAP") &&	/* to prevent a security hole */
	    strcmp(varp, "TERMINFO") &&	/* with tgetent */
	    strcmp(varp, "TERMPATH") &&
	    strcmp(varp, "HOME") &&	/* to prevent the tegetent bug  */
	    strncmp(varp, "LD_", strlen("LD_")) &&	/* most systems */
	    strncmp(varp, "_RLD_", strlen("_RLD_")) &&	/* IRIX */
	    strcmp(varp, "LIBPATH") &&			/* AIX */
	    strcmp(varp, "ENV") &&
	    strcmp(varp, "BASH_ENV") &&
	    strcmp(varp, "IFS") &&
	    strncmp(varp, "KRB5", strlen("KRB5")) &&	/* Krb5 */
	    /*
	     * The above case is a catch-all for now.  Here are some of
	     * the specific ones we must avoid passing, at least until
	     * we can prove it can be done safely.  Keep this list
	     * around un case someone wants to remove the catch-all.
	     */
	    strcmp(varp, "KRB5_CONFIG") &&		/* Krb5 */
	    strcmp(varp, "KRB5CCNAME") &&		/* Krb5 */
	    strcmp(varp, "KRB5_KTNAME") &&		/* Krb5 */
	    strcmp(varp, "KRBTKFILE") &&		/* Krb4 */
	    strcmp(varp, "KRB_CONF") &&			/* CNS 4 */
	    strcmp(varp, "KRB_REALMS") &&		/* CNS 4 */
	    strcmp(varp, "RESOLV_HOST_CONF"))		/* Linux */

Ez egy jo iranyvonal szerintem. Nyilvan nem lehet tokeletes filtert alkotni, mert olyan nincsen, de neked nem egy undefined Unixert kell most felelned, hanem egy AIX-ert, ami - ugy nezem - meg tamogatva is vagyon.
--
Blog | @hron84
Üzemeltető macik

Majdnem: most mint a dtelnet maintainere kavargok, mivel a new environment című feature-t szeretném implementálni. Na ehhez nem árt, ha a szerver fogadja a változókat...

Note: ugyanez ssh-ban a /etc/ssh/sshd_config!AcceptEnv beállítás