Re: telnetd vulnerability from BUGTRAQ
ftp == good enough for public upload and download in a chroot environment. scp == the preferred method for data transfer between machines. Nearly as fast on semi-modern machines. pscp == the windows equivalent for regault *NIXX scp. These are fashion statements. What is wrong with FTP? It provides fast ( as long as files aren't too small ) secure ( encrypted, requires no shell accounts on server ) and easy ( lftp anyone? ) method of transferring files. We should get rid of TelnetD (The Telnet Daemon) For practical purposes Why exactly? Fashion comes and goes... -- Dariush Pietrzak, Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
On 28 Sep 2004, Dariusz Pietrzak wrote: ftp == good enough for public upload and download in a chroot environment. scp == the preferred method for data transfer between machines. Nearly as fast on semi-modern machines. pscp == the windows equivalent for regault *NIXX scp. What is wrong with FTP? It provides fast ( as long as files aren't too small ) secure ( encrypted, requires no shell accounts on server ) and easy ( lftp anyone? ) method of transferring files. Fast I would concede, and easy is a matter of taste, mostly. I don't know what you imagine is encrypted in FTP, though, since that is not part of the specification or the standard implementations. Unless you run an SSL-enhanced or Kerberos FTP client and server, within the same realm, there is no encryption involved in FTP. Daniel -- A man can no more diminish God's glory by refusing to worship Him than a lunatic can put out the sun by scribbling the word 'darkness' on the walls of his cell. -- C. S. Lewis, _The problem of pain_ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
I don't know what you imagine is encrypted in FTP, though, since that is not part of the specification or the standard implementations. oh, not part of THIS: http://www.ietf.org/rfc/rfc2246.txt specification? that is like, what, 5 years old? Well, what about this: http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html and this: http://www.faqs.org/ftp/internet-drafts/draft-murray-auth-ftp-ssl-13.txt and this: http://www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-TLS.html, and this http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html#client And this is fully supported by debian, we've got excellent client (lftp), excelent server (proftpd) and funky server (wzdftpd), so there's something for everyone. I think noone uploaded tlswrap yet, although I've been using it with success and on many platforms for ~2 years now. I would suggest updating one's knowledge at least every ~5 years or so... (it's easy for me to say, because i'm still learning, maybe people with decades of IT experience find it more difficult to follow development of standards) -- Dariush Pietrzak, Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
On 28 Sep 2004, Dariush Pietrzak wrote: I don't know what you imagine is encrypted in FTP, though, since that is not part of the specification or the standard implementations. oh, not part of THIS: http://www.ietf.org/rfc/rfc2246.txt specification? that is like, what, 5 years old? Why, no. That specification being for TLS, it has very little to do with the specification for the FTP protocol. It does mention it, once, as an application level protocol that could benefit from the introduction of TLS, though. Well, what about this: http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html and this: http://www.faqs.org/ftp/internet-drafts/draft-murray-auth-ftp-ssl-13.txt ...now, /that/ is closer to evidence in favour of your statements. It is, however, a draft document, even if it is close to becoming a standard. That isn't a strong basis for any claim that the standard does include encryption, or that encryption is a standard part of FTP. That said, I was partially wrong - there is broader support for TLS in FTP than I was aware of, reviewing the set of implementations listed with that draft. Regards, Daniel -- It is preoccupation with possessions, more than anything else, that prevents us from living freely and nobly. -- Bertrand Russell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
Why, no. That specification being for TLS, it has very little to do correct, sorry, I pasted wrong link, http://www.faqs.org/ftp/internet-drafts/draft-murray-auth-ftp-ssl-13.txt but still, this draft is already several years old, I wrote perl ftp client based on it ~1 year ago, last time I looked at it it had ~1999 date on it, now it looks like it's moving further down the standarisation road... standard. That isn't a strong basis for any claim that the standard does include encryption, or that encryption is a standard part of FTP. I respectfully disagree with you on that point. But I think we've already driffted offtopic... -- Dariush Pietrzak, Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
On Sun, 2004-09-26 at 18:58 -0600, s. keeling wrote: No-one should have to apologise for warning against bad security practices. $DEITY knows the Windows crowd doesn't care about it, but we're better than that, right? One unpatched Microsh*t box in your LAN, and one nitwit using IE, and your whole network is owned. It would be irresponsible not to warn others about it. If/when they get in, they can also get a sniffer in. If you're running telnet, you're fooling yourself. If you're using ssh ubiquitously, that's yet another vector closed to them. I don't have a lot of patience for those who think, Yes, we know the risks, but we'd rather not change. Evolution in action, indeed. This kind of attitude is not very productive. Some people still need telnet. So it should be patched, otherwise it should be removed from the archive. End of discussion. -- David Stanaway [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
On Mon, 27 Sep 2004 at 04:08:38PM -0400, Greg Folkert wrote: I have no problems with scp, best part there isn't the mistaken problem of transfer in ASCII mode, when it should be in IMAGE mode (or BINARY mode) or Vice-Versa. ASCII mode actually serves a purpose when you are communicating with a machine that uses EBCDIC. If you specify ASCII file mode, the EBCDIC machine is responsible for doing the EBCDIC to ASCII conversation. If you just ask for Binary you'll get garbage when you open the file because it is in EBCDIC! (I have this experience from an IBM MVS Environment). -- Phillip Hofmeister pgp22WChho3mU.pgp Description: PGP signature
Re: telnetd vulnerability from BUGTRAQ
On Tue, 28 Sep 2004 at 03:23:15AM -0400, Daniel Pittman wrote: Fast I would concede, and easy is a matter of taste, mostly. I don't know what you imagine is encrypted in FTP, though, since that is not part of the specification or the standard implementations. Unless you run an SSL-enhanced or Kerberos FTP client and server, within the same realm, there is no encryption involved in FTP. I would put forth SSH is no more secure than FTP is when one is dealing with an unknown host. SSH is dependant on a know_host. If information about a host is not known (public/server key) then SSH is every bit as easy to eaves drop as FTP. There are many tools that will easily attempt a man-in-the-middle SSH attack. -- Phillip Hofmeister -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
Dale Amon wrote: The question asked was why is anyone still using telnet when there is ssh. [snip] So no, I was not replying about Debian fixes, I was replying to the general question of 'why telnet at all'. I know I will open a can of worms here, but telnet might actually be a better solution than ssh if you are using IPSec. I would say IPSec obsoletes ssh in favour of telnet. - Adam -- Building your applications one byte at a time http://www.galacticasoftware.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
--- Adam Majer [EMAIL PROTECTED] wrote: I know I will open a can of worms here, but telnet might actually be a better solution than ssh if you are using IPSec. I would say IPSec obsoletes ssh in favour of telnet. The reasoning behind using ssh, even when using IPSec, is a simple matter of having Security in Layers. This is the choice that you make, but personally, I would rather a cracker have to go through the center of the earth to get to my network, rather than crashing through another entrance... = -UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity.-Dennis Ritchie ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
On Mon, Sep 27, 2004 at 12:59:28PM +0100, Steve Kemp wrote: On Mon, Sep 27, 2004 at 01:17:47PM +0200, Milan Jurik wrote: Yes, it's time to look at the sources and find the truth. This appears to have been addressed by the patch in DSA-070-1, so you should be able to apply that to current sources with a small amount of work. Although the .diff.gz file has gone from Debian's mirrors you can see a proposed patch in the original Bugtraq mail: http://www.securityfocus.com/archive/1/203000 I hope that helps those who still run telnetd for whatever reason. (From the advisory it suggests that Debian runs telnetd as its own user, so it's not a remote root at least. Unless you have an unpatched kernel or other hole available for exploitation). As far as we are aware, it is not a remote code execution exploit at all, but only a DoS. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=273694 -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
On Mon, 2004-09-27 at 09:24 +0200, Dariush Pietrzak wrote: The point remains that while telnet/ftp should be treated as deprecated Why is that exactly? There is no replacement for ftp, and I don't know of any problems with it? Please enlighten me. ftp == good enough for public upload and download in a chroot environment. scp == the preferred method for data transfer between machines. Nearly as fast on semi-modern machines. pscp == the windows equivalent for regault *NIXX scp. I have no problems with scp, best part there isn't the mistaken problem of transfer in ASCII mode, when it should be in IMAGE mode (or BINARY mode) or Vice-Versa. We should get rid of TelnetD (The Telnet Daemon) For practical purposes beyond place where there is no option, keep the telnet Client. About the only thing I can think of that is useful for port 23 == mud'ing At the very least, telnetd should not ever be installed as default. -- [EMAIL PROTECTED] REMEMBER ED CURRY! http://www.iwethey.org/ed_curry Novell's Directory Services is a competitive product to Microsoft's Active Directory in much the same way that the Saturn V is a competitive product to those dinky little model rockets that kids light off down at the playfield. -- Thane Walkup signature.asc Description: This is a digitally signed message part
Re: telnetd vulnerability from BUGTRAQ
On Mon, Sep 27, 2004 at 04:08:38PM -0400, Greg Folkert wrote: On Mon, 2004-09-27 at 09:24 +0200, Dariush Pietrzak wrote: The point remains that while telnet/ftp should be treated as deprecated Why is that exactly? There is no replacement for ftp, and I don't know of any problems with it? Please enlighten me. ftp == good enough for public upload and download in a chroot environment. Pure ftp isn't suitable for this. MIM-attacks and data-corruption en route. There's no need for a chroot, though, as long as you're using a sane ftpd. scp == the preferred method for data transfer between machines. Nearly as fast on semi-modern machines. pscp == the windows equivalent for regault *NIXX scp. Unfortunately, scp requires a shell access, doesn't play well with caching proxies, and is in fact quite resource-hungry. But the main objection is, ssh provides the presentation layer functionality on the application layer. Which is why you really should not preach it as a panacea. Cheers, -- Jan pgppCNfvA2Gmi.pgp Description: PGP signature
Re: telnetd vulnerability from BUGTRAQ
Quoting Jan Minar ([EMAIL PROTECTED]): Unfortunately, scp requires a shell access http://www.sublimation.org/scponly/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
On Mon, Sep 27, 2004 at 02:54:49PM -0700, Rick Moen wrote: Quoting Jan Minar ([EMAIL PROTECTED]): Unfortunately, scp requires a shell access http://www.sublimation.org/scponly/ I've been using scponly for a while now as a replacement for FTP. Never had any complaints or problems. I also use scponly with scpjailer [1] which creates a nice chroot environment based on BusyBox. [1] http://tjw.org/scpjailer/ David. -- .''`. David Ramsden [EMAIL PROTECTED] : :' :http://david.hexstream.eu.org/ `. `'` PGP key ID: 507B379B on wwwkeys.pgp.net `- Debian - when you have better things to do than to fix a system. pgpS89pMrRsGB.pgp Description: PGP signature
Re: telnetd vulnerability from BUGTRAQ
On Mon, Sep 27, 2004 at 02:54:49PM -0700, Rick Moen wrote: Quoting Jan Minar ([EMAIL PROTECTED]): Unfortunately, scp requires a shell access http://www.sublimation.org/scponly/ Of course, but this is even more non-standard then ssh proper, and a recent project, so no scponly in woody btw. -- Jan pgpanGtxrE82L.pgp Description: PGP signature
Re: telnetd vulnerability from BUGTRAQ
Hi, so, again, for some locked people. There is maybe an application in Debian which is remotely exploitable. This application will be probably also in the next stable release. This thread is about this situation. I (and some other people) use telnetd only in very specific situations where isn't any other possibility. I don't like using of telnetd and I know about the risks and I do necessary actions for minimized them! You have probably all your systems 10 meters around you. I have some systems which are thousands kilometers far. Please, stop speaking about the Holy Grail (sshd) and go to the fundamental thing - is or isn't one standard Debian application remotely exploitable. Yes, it's time to look at the sources and find the truth. Best regards, Milan Jurik On Sun, 26 Sep 2004, s. keeling wrote: Incoming from Rick Moen: Quoting Milan Jurik ([EMAIL PROTECTED]): The question isn't if stop using telnet. The question is why Debian's telnetd is still vunerable. I'd apologise for the off-topic digression -- if I thought I'd given offence. ;- No-one should have to apologise for warning against bad security practices. $DEITY knows the Windows crowd doesn't care about it, but we're better than that, right? One unpatched Microsh*t box in your LAN, and one nitwit using IE, and your whole network is owned. It would be irresponsible not to warn others about it. If/when they get in, they can also get a sniffer in. If you're running telnet, you're fooling yourself. If you're using ssh ubiquitously, that's yet another vector closed to them. I don't have a lot of patience for those who think, Yes, we know the risks, but we'd rather not change. Evolution in action, indeed. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - -
Re: telnetd vulnerability from BUGTRAQ
On Mon, Sep 27, 2004 at 01:17:47PM +0200, Milan Jurik wrote: Yes, it's time to look at the sources and find the truth. This appears to have been addressed by the patch in DSA-070-1, so you should be able to apply that to current sources with a small amount of work. Although the .diff.gz file has gone from Debian's mirrors you can see a proposed patch in the original Bugtraq mail: http://www.securityfocus.com/archive/1/203000 I hope that helps those who still run telnetd for whatever reason. (From the advisory it suggests that Debian runs telnetd as its own user, so it's not a remote root at least. Unless you have an unpatched kernel or other hole available for exploitation). Steve --
Re: telnetd vulnerability from BUGTRAQ
On Friday, 24 September 2004, at 16:15:09 -0600, s. keeling wrote: Is anyone still using telnet when there's ssh? Why? I wouldn't even use it inside my own firewalled LAN. ssh is just better. Yes, many people have a curious sense of computer security. They ask for mega-cool (and MEGA expensive) hardware commercial firewalls but keep on using telnet to access remote boxes (even using root or similarly privileges accounts). Maybe customers just ask for what we are offering them, and there seems to be little market (in money terms) for SSH implementations, so they are told about the needs of high-end firewalls and IDS, but not warned about simpler, cheaper and more important things like not using telnet (or even r-commands). Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.9-rc1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
On Saturday, 25 September 2004, at 10:34:43 -0500, hanasaki wrote: When IPSEC is being used, telnet works the same; however is secure because it, like all traffic, is sent over a transparent tunnel. But an IPsec tunnel encrypts traffic just between the tunnel endpoints. But this need not to be the full path between the telnet client and server, so anyone sniffing (for example) on your destination LAN will get you usernames and passwords easily. Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.9-rc1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
On Sat, Sep 25, 2004 at 12:13:26PM +0200, Jan Minar wrote: On Fri, Sep 24, 2004 at 04:15:09PM -0600, s. keeling wrote: Is anyone still using telnet when there's ssh? Why? I wouldn't even use it inside my own firewalled LAN. ssh is just better. I've been told telnet *does* make a lot of sense where IPSEC is set up. Or OPIE, if you only care about keeping the password secret. ssh has encryption overhead, which in the PC world isn't a big deal. However, when you think embedded devices (ssh or telnet from you PDA), it begins to have an impact. Battery life, for example. -- Lee Sheridan [EMAIL PROTECTED] I know engineers, they love to change things. -Dr. McCoy, Star Trek I -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
Quoting Milan Jurik ([EMAIL PROTECTED]): The question isn't if stop using telnet. The question is why Debian's telnetd is still vunerable. I'd apologise for the off-topic digression -- if I thought I'd given offence. ;- -- Cheers,A raccoon tangled with a 23,000 volt line, today. The results Rick Moen blacked out 1400 homes and, of course, one raccoon. [EMAIL PROTECTED] -- Steel City News -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
Incoming from Rick Moen: Quoting Milan Jurik ([EMAIL PROTECTED]): The question isn't if stop using telnet. The question is why Debian's telnetd is still vunerable. I'd apologise for the off-topic digression -- if I thought I'd given offence. ;- No-one should have to apologise for warning against bad security practices. $DEITY knows the Windows crowd doesn't care about it, but we're better than that, right? One unpatched Microsh*t box in your LAN, and one nitwit using IE, and your whole network is owned. It would be irresponsible not to warn others about it. If/when they get in, they can also get a sniffer in. If you're running telnet, you're fooling yourself. If you're using ssh ubiquitously, that's yet another vector closed to them. I don't have a lot of patience for those who think, Yes, we know the risks, but we'd rather not change. Evolution in action, indeed. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - -
Re: telnetd vulnerability from BUGTRAQ
In the non-unix world, telnet is still a necessity :( Yes, I have putty on *my* windows boxen... But there are still significant numbers of boxes that I use - MVS/VM (z/OS), W2k, etc. that require me to allow directed telnet to my laptop/workstation. Just because there is a H2 on the block, doesn't mean that the original VW bug is now no longer needed... -- Rick Nelson Linux supports the notion of a command line or a shell for the same reason that only children read books with only pictures in them. Language, be it English or something else, is the only tool flexible enough to accomplish a sufficiently broad range of tasks. -- Bill Garrett -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
Quoting Richard A Nelson ([EMAIL PROTECTED]): Yes, I have putty on *my* windows boxen... But there are still significant numbers of boxes that I use - MVS/VM (z/OS)... OpenSSH works on MVS. See: http://www.stdnet.com/uploads/media/MOVEit-DMZ-Compatible-Clients.PDF. , W2k, etc. Innumerable SSH implementations work on MS-Windows 2000. See: http://linuxmafia.com/ssh/win32.html For others, please see: http://linuxmafia.com/ssh/ ...that require me to allow directed telnet to my laptop/workstation. Maybe, but not the ones you mentioned. -- Cheers, The cynics among us might say: We laugh, Rick Moen monkeyboys -- Linux IS the mainstream UNIX now! [EMAIL PROTECTED] MuaHaHaHa! but that would be rude. -- Jim Dennis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
On Fri, Sep 24, 2004 at 04:15:09PM -0600, s. keeling wrote: Is anyone still using telnet when there's ssh? Why? I wouldn't even use it inside my own firewalled LAN. ssh is just better. I've been told telnet *does* make a lot of sense where IPSEC is set up. Cheers, -- Jan pgpmCTv4JivXx.pgp Description: PGP signature
Re: telnetd vulnerability from BUGTRAQ
Jan Minar wrote: On Fri, Sep 24, 2004 at 04:15:09PM -0600, s. keeling wrote: Is anyone still using telnet when there's ssh? Why? I wouldn't even use it inside my own firewalled LAN. ssh is just better. I've been told telnet *does* make a lot of sense where IPSEC is set up. Cheers, When IPSEC is being used, telnet works the same; however is secure because it, like all traffic, is sent over a transparent tunnel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
On Sat, 25 Sep 2004, Rick Moen wrote: Quoting Richard A Nelson ([EMAIL PROTECTED]): Yes, I have putty on *my* windows boxen... But there are still significant numbers of boxes that I use - MVS/VM (z/OS)... OpenSSH works on MVS. See: http://www.stdnet.com/uploads/media/MOVEit-DMZ-Compatible-Clients.PDF. Yes indeed, but MVS isn't an OS where mere mortals get to install software... So I'd most likely be stuck with only client support. MVS is getting telnet-SSL support also - and I use that where I can , W2k, etc. Innumerable SSH implementations work on MS-Windows 2000. See: http://linuxmafia.com/ssh/win32.html I typically use cygwin on *MY* laptop, but when away from that - I try not to install random software on other's boxen For others, please see: http://linuxmafia.com/ssh/ ...that require me to allow directed telnet to my laptop/workstation. Maybe, but not the ones you mentioned. ok, I should've said to/from my laptop (and occaisionally other boxen) The point remains that while telnet/ftp should be treated as deprecated when feasible, sometimes there just aren't alternatives... and even stock w98 had a built-in telnet client. -- Rick Nelson Besides, its really not worthwhile to use more than two times your physical ram in swap (except in a select few situations). The performance of the system becomes so abysmal you'd rather heat pins under your toenails while reciting Windows95 source code and staring at porn flicks of Bob Dole than actually try to type something. -- seen on c.o.l.development.system, about the size of the swap space -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
Quoting Richard A Nelson ([EMAIL PROTECTED]): [Snip MVS mainframe priesthood standing in way of OpenSSH installation.] I typically use cygwin on *MY* laptop, but when away from that - I try not to install random software on other's boxen The usual remedy is to pull down putty.exe (tiny) and launch it directly from download, in which case it exists on disk only briefly in your browser cache. This works even on locked-down cybercafe machines that won't allow you to run apps off your flash/floppy/mini-CD drive. ok, I should've said to/from my laptop (and occaisionally other boxen) Try PuTTY. You'll like it. The point remains that while telnet/ftp should be treated as deprecated when feasible, sometimes there just aren't alternatives. My entire document (http://linuxmafia.com/ssh) is devoted to documenting why that argument fails to hold water. ;- (Reminds me: I should mention, there, that MVS port.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
On Sat, Sep 25, 2004 at 10:34:43AM -0500, hanasaki wrote: Jan Minar wrote: On Fri, Sep 24, 2004 at 04:15:09PM -0600, s. keeling wrote: Is anyone still using telnet when there's ssh? Why? I wouldn't even use it inside my own firewalled LAN. ssh is just better. I've been told telnet *does* make a lot of sense where IPSEC is set up. When IPSEC is being used, telnet works the same; however is secure because it, like all traffic, is sent over a transparent tunnel. One very good reason to avoid it even in tunnels is that you get into bad habits. One tired night you forget and connect over an unsecured link to a key machine... and you're toast. -- -- Dale Amon [EMAIL PROTECTED]+44-7802-188325 International linux systems consultancy Hardware software system design, security and networking, systems programming and Admin Have Laptop, Will Travel -- signature.asc Description: Digital signature
Re: telnetd vulnerability from BUGTRAQ
Hi, On Sat, 25 Sep 2004, Rick Moen wrote: Quoting Richard A Nelson ([EMAIL PROTECTED]): The point remains that while telnet/ftp should be treated as deprecated when feasible, sometimes there just aren't alternatives. My entire document (http://linuxmafia.com/ssh) is devoted to documenting why that argument fails to hold water. ;- (Reminds me: I should mention, there, that MVS port.) The question isn't if stop using telnet. The question is why Debian's telnetd is still vunerable. Sometimes when I make large changes on my servers (sometimes a bit far from me), I use telnetd (the ssl version, so password is a bit secure than plain telnet) as a backup. When sshd is changed, when I modified iptables around 22 etc. Yes, of course, I setup timeouts for those changes, but it isn't important (reboot is a bad solution). The important question is: Is telnetd still supported in Debian? Or is this security bug unreal? Best regards, Milan Jurik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
Incoming from James Renken: Greetings, I noticed the message below on BUGTRAQ last weekend, reporting a remote root compromise in telnetd. I haven't seen any discussion of this on the list archives, nor a new DSA. Am I missing something? Is anyone still using telnet when there's ssh? Why? I wouldn't even use it inside my own firewalled LAN. ssh is just better. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
On Fri, Sep 24, 2004 at 04:15:09PM -0600, s. keeling wrote: Is anyone still using telnet when there's ssh? Why? I wouldn't even use it inside my own firewalled LAN. ssh is just better. Unfortuneately if you use Cisco gear you are pretty much stuck. Some of the older stuff just doesn't have the mips to deal with it even if installed and I believe Cisco charges an arm and a leg for the upgrade. I've never had a Cisco with it installed. So use, if you work with routers, you are stuck. -- -- Dale Amon [EMAIL PROTECTED]+44-7802-188325 International linux systems consultancy Hardware software system design, security and networking, systems programming and Admin Have Laptop, Will Travel -- signature.asc Description: Digital signature
Re: telnetd vulnerability from BUGTRAQ
On Fri, Sep 24, 2004 at 11:24:54PM +0100, Dale Amon wrote: On Fri, Sep 24, 2004 at 04:15:09PM -0600, s. keeling wrote: Is anyone still using telnet when there's ssh? Why? I wouldn't even use it inside my own firewalled LAN. ssh is just better. Unfortuneately if you use Cisco gear you are pretty much stuck. Some of the older stuff just doesn't have the mips to deal with it even if installed and I believe Cisco charges an arm and a leg for the upgrade. I've never had a Cisco with it installed. Cisco gear contains the Debian telnetd? And if that's true, how would us releasing a DSA for it necessarily help all the Cisco routers out there. We're not talking about the general intelligence of using telnet (or, at least, that wasn't the initial topic of discussion), but rather the possibility of fixing security problems in the stock telnetd in Debian. - Matt signature.asc Description: Digital signature
Re: telnetd vulnerability from BUGTRAQ
On Fri, 24 Sep 2004, s. keeling wrote: I noticed the message below on BUGTRAQ last weekend, reporting a remote root compromise in telnetd. I haven't seen any discussion of this on the list archives, nor a new DSA. Am I missing something? Is anyone still using telnet when there's ssh? Why? I wouldn't even use it inside my own firewalled LAN. ssh is just better. Agreed - but some of my customers, even after I've pointed out the risks, just don't want to go through the trouble of changing from their preferred Telnet programs. Given that a remote root is supposedly possible, I think this should be looked at, no matter how rare the package's usage may be. -- James Renken, System Administrator [EMAIL PROTECTED] Sandwich.Net Internet Services http://www.sandwich.net/ 1-877-HUBWICH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
On Sat, Sep 25, 2004 at 08:28:13AM +1000, Matthew Palmer wrote: Cisco gear contains the Debian telnetd? And if that's true, how would us releasing a DSA for it necessarily help all the Cisco routers out there. We're not talking about the general intelligence of using telnet (or, at least, that wasn't the initial topic of discussion), but rather the possibility of fixing security problems in the stock telnetd in Debian. The question asked was why is anyone still using telnet when there is ssh. And I would say that Cisco and some other gear are about the only reasons why anyone would still make a connection with the telnet protocol (other than for testing odd things... I used to use 'telnet foo 110' to hand test my company pop server when someone had problems. So no, I was not replying about Debian fixes, I was replying to the general question of 'why telnet at all'. -- -- Dale Amon [EMAIL PROTECTED]+44-7802-188325 International linux systems consultancy Hardware software system design, security and networking, systems programming and Admin Have Laptop, Will Travel -- signature.asc Description: Digital signature
Re: telnetd vulnerability from BUGTRAQ
Quoting James Renken ([EMAIL PROTECTED]): Agreed - but some of my customers, even after I've pointed out the risks, just don't want to go through the trouble of changing from their preferred Telnet programs. ObNivenAndPournelle: Think of it as evolution in action. -- Cheers, Rick Moen vi is my shepherd; I shall not font. [EMAIL PROTECTED] -- Psalm 0.1 beta -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: telnetd vulnerability from BUGTRAQ
On Fri, 2004-09-24 at 18:35, Dale Amon wrote: On Sat, Sep 25, 2004 at 08:28:13AM +1000, Matthew Palmer wrote: Cisco gear contains the Debian telnetd? And if that's true, how would us releasing a DSA for it necessarily help all the Cisco routers out there. We're not talking about the general intelligence of using telnet (or, at least, that wasn't the initial topic of discussion), but rather the possibility of fixing security problems in the stock telnetd in Debian. The question asked was why is anyone still using telnet when there is ssh. And I would say that Cisco and some other gear are about the only reasons why anyone would still make a connection with the telnet protocol (other than for testing odd things... I used to use 'telnet foo 110' to hand test my company pop server when someone had problems. I totally agree that ssh should definately be used if available, but telnetd has saved me more than once. For example, I am responsible for maintaining machines all over the world, and telnet will allow me to login more quickly than ssh if the machine is under some extremely high load and is about to crash without intervention. I've also had some twit administrator change the permissions on an ssh directory, or run ssh-keygen without thinking, and as a result I'm unable to connect via ssh. telnet is all that saved me from waking somebody up at 3am to get access to a machine in another country. In addition, some machines I maintain are rather old, and the load caused by ssh has become a concern on these machines. Also, you try finding ssh-client rpms for Redhat Manhattan (5.0) which will properly and reliably communicate with any recent version of sshd. (Note that in all these examples I've been telnet'ing over a private frame connection or VPN). So no, I was not replying about Debian fixes, I was replying to the general question of 'why telnet at all'. signature.asc Description: This is a digitally signed message part
