Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top says:

The telnet protocol allows to pass environment variables inside the telnet traffic and assign them to the other side of the tcp connection. The telnet daemon of FreeBSD 7.0-RELEASE does not check for LD_* (like LD_PRELOAD) environment variables prior to executing /bin/login. So passing an environment variable with the identifier LD_PRELOAD and the value of a precompiled library that is on the filesystem of the victims box that includes malicious code is possible. When /bin/login is executed with the user id and group id 0 ('root') it preloads the library that was set by remote connection through a telnet environment definition and executes it. It is unlikely that this bug can be exploited remotely but is not impossible. An attacker could f.e. upload a malicious library using ftp (including anonymous ftp users), nfs, smb or any other (file) transfer protocol. One scenario to exploit the bug remotely would be a ftp server running beside the telnet daemon serving also anoynmous users with write access. Then the attacker would upload the malicious library and defines the LD_PRELOAD variable to something similar to /var/ftp/ to gain remote root access.

So, if I create a new telnet and inetd under a non-super user, is this exploit not working? It seems so as /bin/login must be executed with the user id of root, but I am not sure if /bin/login is always executed as the user id of root...

share|improve this question
I would question why run telnet at all? Why not SSH? And /bin/login will have SUID bit set usually. – ewanm89 Sep 22 '12 at 16:06
@ewanm89 but the exploit I mentioned was about telnet... And I am just testing my machine.. to learn penetration testing. Or are you saying that the exploit can be changed into SSH exploit? – AAAAAAA Sep 23 '12 at 0:16
Ah okay, makes more sense, just don't expect telnet to be a common target. If you so much as find it, it should probably be reported as bad to start with. – ewanm89 Sep 23 '12 at 11:12
@ewanm89 So, what I am doing is, there is telnet running, but suppose that I restrict myself to a non-privileged user. The user can upload files into /tmp only, and using this directory, the user installs a new inetd server and a new telnet server, owned by the user. Then, from another machine, I connect to the machine that runs telnet server, launches an exploit that passes unchecked environment variables and executes /bin/login. The question is, would this way even be able to execute /bin/login? Also, if it does, would this pass unchecked environment variables successfully? – AAAAAAA Sep 23 '12 at 11:18
Or, you can suppose that telnet was originally not running - it does not matter anyway. – AAAAAAA Sep 23 '12 at 11:19

No. I think the described vulnerability existed because the target telnet daemon ran with root privileges and allowed the client to define LD_PRELOAD= value that would be used when running /bin/login as root.

Setting LD_PRELOAD environment variable for a root process allowed the attacker to point to a specific library (arbitrary code) that would be executed as the root user.

The host operating system knows that LD_PRELOAD must be ignored if a setuid() binary is called .

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.