Everything, Everything

2024: January February March April
2023: J F M A M J J A S O N D
2022: J F M A M J J A S O N D
2021: J F M A M J J A S O N D
2020: J F M A M J J A S O N D
2019: J F M A M J J A S O N D
2018: J F M A M J J A S O N D
2017: J F M A M J J A S O N D
2016: J F M A M J J A S O N D
2015: J F M A M J J A S O N D
2014: J F M A M J J A S O N D
2013: J F M A M J J A S O N D
2012: J F M A M J J A S O N D
2011: J F M A M J J A S O N D
2010: J F M A M J J A S O N D
2009: J F M A M J J A S O N D
2008: J F M A M J J A S O N D
2007: J F M A M J J A S O N D
2006: J F M A M J J A S O N D
2005: J F M A M J J A S O N D
2004: J F M A M J J A S O N D
telnetd
Tuesday 3rd April, 2007 23:55 Comments: 0
With all the fuss over a few Windows exploits using the ANI vulnerability, people may not have heard about another problem with telnetd. Sure, people shouldn't use telnetd, just like people shouldn't use ftp anymore, as it's all sent in clear text, but people still do. It seems that the MIT krb5 telnet daemon (telnetd) up to and including krb5-1.6 allows unauthorized login as an arbitrary user, when presented with a specially crafted username. Exploitation of this vulnerability is trivial. A user can gain unauthorized access to any account (apparently including root) on a host running telnetd. Whether the attacker needs to authenticate depends on the configuration of telnetd on that host. A malformed username beginning with "-e" can be interpreted as a command-line flag by the login.krb5 program, which is executed by telnetd. This causes login.krb5 to execute part of the BSD rlogin protocol, where an arbitrary username may be injected, allowing login as that user without a password or any further authentication. If the telnet daemon is configured to only permit authenticated login, then only authenticated users can exploit this vulnerability. This is a somewhat similar problem to the telnetd bug seen on Solaris 10 and 11, where the use of a flag results in telnetd passing information to the login process and ultimately allowing attackers to log on as arbitrary users. It's not just Microsoft that screw up. People may criticize Microsoft, but when was the last time you saw such a trivial way into a system*? Also, see this comment to see why it took Microsoft so long to patch the ANI vulnerability.

* from memory, it's probably MS06-009 for those of you running XP or 2003 with Korean language support and Remote Desktop enabled, but it did require a fair bit of clicking to get there
© Robert Nicholls 2002-2024
The views and opinions expressed on this site do not represent the views of my employer.
HTML5 / CSS3