Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Security Bug Network Networking

Cisco Fixes Three-Year-Old Telnet Flaw In Security Appliances 60

Posted by timothy from the but-telnet's-otherwise-fine? dept.
Trailrunner7 writes "There is a severe remote code execution vulnerability in a number of Cisco's security appliances, a bug that was first disclosed nearly three years ago. The vulnerability is in Telnet and there has been a Metasploit module available to exploit it for years. The FreeBSD Project first disclosed the vulnerability in telnet in December 2011 and it was widely publicized at the time. Recently, Glafkos Charalambous, a security researcher, discovered that the bug was still present in several of Cisco's security boxes, including the Web Security Appliance, Email Security Appliance and Content Security Management Appliance. The vulnerability is in the AsyncOS software in those appliances and affects all versions of the products." At long last, though, as the article points out, "Cisco has released a patched version of the AsyncOS software to address the vulnerability and also has recommended some workarounds for customers."
This discussion has been archived. No new comments can be posted.

Cisco Fixes Three-Year-Old Telnet Flaw In Security Appliances More

Cisco Fixes Three-Year-Old Telnet Flaw In Security Appliances

Comments Filter:

  • Security + Telnet (Score:5, Insightful)

    by MightyYar ( 622222 ) on Thursday October 23, 2014 @09:07AM (#48212419)

    Security + Telnet = My Brain Hurts

    • Re:Security + Telnet (Score:5, Insightful)

      by 3.5 stripes ( 578410 ) on Thursday October 23, 2014 @09:12AM (#48212445)

      Yeah, any sort of security guidelines should have at the top, in the largest boldest letters possible, DO NOT USE TELNET.

      • Re:Security + Telnet (Score:4, Interesting)

        by silas_moeckel ( 234313 ) <silas AT dsminc-corp DOT com> on Thursday October 23, 2014 @09:16AM (#48212469) Homepage

        I use telnet plenty great for connecting to a tcp port and debugging. It's a horrid thing to run as a service and allow people to login etc.

        • Use netcat (aka nc) for that. It works just as well and you can just ^C to get out of it.

          • Oh? I was unaware that Cisco equipment came with netcat.

            • This is about talking to Cisco not from Cisco.

              • Re: (Score:2)

                by jandrese ( 485 )
                Often times you have to do both, thanks to security policies that prevent user machines from connecting directly with routers/switches. The admin jumps on the box with a serial cable and uses telnet from there to talk to the other equipment.

                • The point is: Do not run telnetd on a security device.

                  Running a telnet client to check a port/connection has not the same implications as using a telnet session to manage a security device.

        • Re:Security + Telnet (Score:5, Informative)

          by CaptnZilog ( 33073 ) on Thursday October 23, 2014 @09:24AM (#48212527)

          I use telnet plenty great for connecting to a tcp port and debugging. It's a horrid thing to run as a service and allow people to login etc.

          Yeah, the client comes in handy at times to connect to port 80 and 'handcraft' a http request to see a response, etc... but running a telnet server/service on the machine? Especially on a "security" device?!?!? C'mon... that's just ludicrous in all kinds of ways.

          • Re: (Score:2)

            by TWX ( 665546 )
            Depends on how the network is VLANned. I agree, it's not optimal for certain, but in cases where the management team for the devices have one VLAN for just themselves trunked to them, and where they use a common set of credentials to manage (ie, no TACACS/Radius) then it's not really any less secure.

            Admittedly if someone makes a mistake and puts the wrong user on that VLAN, or if they need to get to the devices from elsewhere then they may have to traverse the network before getting to that VLAN, so the
            • Telnet is literally worse than requiring no password for log in.

            • Not really less secure??? How many vulnerability's have there been to inject frames into vlans, Turn access ports into trunks often with the default trunk everything.

        • I use telnet plenty great for connecting to a tcp port and debugging.

          SSH be plenty greater for connecting to TCP ports and not security problem.

          • SSH is for securely connecting to SSH servers. It's not useful, and certainly not "secure", for low level debugging of TCP connections.

            • SSH is for securely connecting to SSH servers. It's not useful, and certainly not "secure", for low level debugging of TCP connections.

              Were you listening to your iPod? Because you missed the loud whooshing sound.

          • Re: (Score:1)

            by Anonymous Coward

            fwiw (I work at cisco) there has been a long-standing bug in sshv2 on most cisco boxes since the heartbleed bug. took me quite a while to find what the problem was in turning on ssh2. ssh1 was easy, but I needed v2 (netconf requires v2, for example).

            turns out, openssl was fixed on linux but not quite fixed (right) on cisco. short answer: you have to run ssh -v2 with a command line 'mess' (or edit a .ssh/config file) to reorder the key exchange listing. if you move some of the kex stuff ahead of others,

            • Hang on... SSL and SSH are not the same! Heartbleed affected OpenSSL!

              fwiw (I work at cisco)

              In HR? Comms?

    • Security + Telnet = My Brain Hurts

      It should hurt..

      However, if memory serves, I think that Cisco provides SSH access and allows you to disable telnet. Even then, suggested practice was to put all your network hardware consoles on a private VLAN and firewall it from general access... So it's understandable that it took some time to fix this given there are multiple work arounds.

    • You sig enthralls me.
      To en tomaten tomaten tomaten to vrat
      To en tom aten tomaten tom at en to vrat.
      (To and Tom ate tomatoes, Tom ate and To devoured).
      (Google Translate: 'To and ate tomatoes tom tom ate and ate to' which is just pathetic).

  • Thank Goodness! (Score:5, Funny)

    by linuxrunner ( 225041 ) on Thursday October 23, 2014 @09:21AM (#48212493)

    I've been waiting for this fix so I can finally drop SSH

  • Telnet (Score:3)

    by ledow ( 319597 ) on Thursday October 23, 2014 @09:24AM (#48212537) Homepage

    Is it just me that wasn't even aware that telnet had an encrypted mode (let alone a horribly-broken one)?

    Not been an issue as I always switch it off unless the device is entirely in-house (and, there, someone sniffing the packets is much more of a problem than the fact they might end up with a device password by doing so).

    Honestly, we just need to kill this "protocol".

    • Is it just me that wasn't even aware that telnet had an encrypted mode

      I just called it SSH.

    • There is even a kerberized telnet for a long time, however still no advantage over ssh which is also kerberized. Telnet should really die once and for all.

  • The funny about Cisco... (Score:4, Interesting)

    by __aaclcg7560 ( 824291 ) on Thursday October 23, 2014 @09:29AM (#48212575)
    When I worked at Cisco for nine months as a contractor last year, everyone used telnet to access network devices under development. My boss explained to me that 1) these were default passwords that everyone on the team knew, and 2) the development VLAN is secured from outsiders. That makes sense on one level, but using telnet is a bad habit one shouldn't get into.

    • TELNET is just the default way to access the equipment. It comes out of the box that way (OK, not really but it's the default way to set up). Think of it as a legacy thing.

      There is nothing wrong with using TELNET on a private network but today we understand that security is better served using SSH for this functionality. However, in some environments, legacy dies hard because TELNET is not really that much of a security risk if you have good control over who accesses your network.

      Sharing passwords and

      • Re: (Score:2)

        by DarkOx ( 621550 )

        here is nothing wrong with using TELNET on a private network but today we understand that security is better served using SSH for this functionality. However, in some environments, legacy dies hard because TELNET is not really that much of a security risk if you have good control over who accesses your network.

        There is nothing right with it! SSH is not an overhead concern for any contemporary device. Even if the only people with access to the networks the management services accept connections from all have access you still have a problem. If there have been credentials running around in the clear we don't really know / can't prove who has been using them. Also it leaves the door open for MITM possiblities where content is injected. TACS logs show Bob issued the "write erase" but we can't really say it wasn'

        • Don't misunderstand me, I'm not advocating TELNET. I'm just not ready to condemn someone for using it for legacy reasons in situations where security is not a huge concern.

          Security is really "risk management". This means that you must weigh the implementation costs and consider the risks. Remember that the ONLY secure system is one that's powered off and not plugged in. And then, it's only as secure as the physical security makes it.

          In a closed network, like in a development lab, I can imagine that t

    • I'd worry anyway. (Score:4, Insightful)

      by khasim ( 1285 ) <brandioch.conner@gmail.com> on Thursday October 23, 2014 @10:04AM (#48212837)

      That makes sense on one level, but using telnet is a bad habit one shouldn't get into.

      I agree. A better habit is setting up and using SSH.

      Not only that but "defense in depth". Do NOT rely upon your perimeter defenses to stop all attacks. It only takes one person with a compromised laptop and you're cracked.

      1) these were default passwords that everyone on the team knew

      SSH can be set up the same.

      2) the development VLAN is secured from outsiders

      Until it is compromised.

      Remember, in defense you have to be right on everything all the time. An attacker can just stumble into something you missed. Like someone's laptop that was brought in when it should not have been.

      • Then too, it may be that Cisco's development lab is really just there to run test software loads. I imagine that they are using TFTP and TELNET for this purpose. Oh the horror! (sarcasm off)

        Where I don't disagree with you, I'm not ready to dump on somebody who chooses to use TELNET for what ever reason. IF they understand the risks and knowingly choose to do it anyway, it's their equipment and their call. You and I might never choose to do it this way, but neither of us are involved so it's not our ch

        • Then too, it may be that Cisco's development lab is really just there to run test software loads. I imagine that they are using TFTP and TELNET for this purpose. Oh the horror! (sarcasm off)

          The entire building was set up that way and kept separate from the actual labs inside the building, being one router hop away from the production network. That router didn't have the same safeguards as the perimeter routers for the outside world. Telnet was disabled on the router.

  • How does a major vendor like Cisco take 3+ years to fix a known security hole?

    Did they just sit on it? Or were they hoping nobody would notice?

    That makes no sense to me at all.

    • From what I can tell in recent times, Cisco lays off 10% of their workforce in America and hires 10% of their workforce from India. The development teams are squeezed in the middle as experienced people are let go and new people are still learning the ropes. It's a rotten business model but apporved by Wall Street.

    • How does a major vendor like Cisco take 3+ years to fix a known security hole?

      Work around existed, nobody ever fielded in a configuration that was subject to the problem, so this was LOW risk. If you are working more important issues, LOW risk stuff gets to wait.

      That's how.

  • However, being accessible by even a single machine you don't trust is not one of those places.

    A place where it is helpful: Isolated networks such as in a test lab that you control. The fact that it is NOT encrypted can be a great asset in debugging if you are looking at packet-capture logs. Sure, there are other solutions but if telnet/telnetd are readily available and they get the job done without causing any bad side-effects in a particular use case why not use them?

    • Re:Telnet has its place (Score:4, Informative)

      by DarkOx ( 621550 ) on Thursday October 23, 2014 @10:17AM (#48212967) Journal

      Because its not what your customers are really going to use! Better to exercise a real world configuration in the lab. Add 'null' cipher to ssh if you need this and make the command to enable it something obviously out of place for normal operations like:

      DangerDoNotUse_EnableSSH_NULL_CIPHER
      DangerDoNotUse_EnableSSH_NULL_MAC

  • Yes, sooner would have been better but at least they got around to fixing it, right?

  • A vulnerability IN Telnet ? (Score:3)

    by alexhs ( 877055 ) on Thursday October 23, 2014 @09:58AM (#48212799) Homepage Journal

    There are vulnerabilities IN Telnet ?
    And I thought Telnet WAS a vulnerability...
    It's vulnerabilities all the way down, I guess.

    • It's vulnerable from a packet sniffer standpoint, but a remote vulnerability makes it worse. Many companies have old Cisco code that doesn't have the feature set to support SSH. Why Cisco thought you should have to buy "firewall feature set" on a router in order to get SSH, even long ago still baffles me. Using SSH to get to a management host and allowing telnet across your data center management LAN only from said management host isn't ideal, but it isn't the greatest security sin.

  • Telnet client = great, telnet server = bad idea (Score:3)

    by Viol8 ( 599362 ) on Thursday October 23, 2014 @11:13AM (#48213581) Homepage

    Don't get the server confused with the client. Telnet servers should have been put out to pasture years ago except perhaps on small isolated networks. The telnet CLIENT however is an extremely useful debugging tool for connecting to all sorts of text based servers (FTP, usenet, HTTP etc) and I get really pissed off with some distributions that assume because the server is no longer used neither is the client and so remove it.

    Also FWIW , telnet is still the default way to access MUDs and some BBSs.

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close