netkit-telnetd elavulta magát

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"

( NevemTeve | 2015. 10. 14., sze – 17:52 )

É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.

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

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 */