back to article Cisco patches three-year-old remote code-execution hole

A three-year-old dangerous remote code execution hole affecting Cisco kit has been patched. Researcher Glafkos Charalambous discovered the Telnet vulnerability (CVE-2011-4862), which was first reported by the FreeBSD Project in 2011. It was left unpatched up prior to 15 October this year in Cisco appliances. The International …

  1. Ruairi

    To be fair, you dont leave your management interfaces exposed to the public at large when you're talking about networking devices.

    *Even* if you're running 10-15 year old kit that does not support SSH, it's in it's own private/management VLAN that's heavily firewalled/no access to the outside world.

  2. A Non e-mouse Silver badge

    Encrypted Telnet?

    The vulnerability is due to insufficient boundary checks when processing telnet encryption keys

    Since when does telnet have encryption keys?!?

    1. Phil O'Sophical Silver badge

      Re: Encrypted Telnet?

      Since when does telnet have encryption keys?!?

      When you use the -x option, or the "encrypt" subcommand.

    2. DougMac

      Re: Encrypted Telnet?

      Since about the year 2000, with RFC 2946.

      *BSD are mainly the only ones that implemented it.

    3. Anonymous Coward
      Anonymous Coward

      Re: Encrypted Telnet?

      this was news to me too, but I notice my slackware/linux box has a -x option for telnet, of which the manpage says:

      -x Turns on encryption of the data stream if Kerberos is used.

  3. ElReg!comments!Pierre

    not very informative...

    I'm sorry, none of this article makes real sense to me; I'm probably not familiar enough with Cisco's "web, email and content security management appliances" (and I thank Dog everyday for that fact, too. It's the little things in life, you know).

    From the BSD bug report:

    II. Problem Description

    When an encryption key is supplied via the TELNET protocol, its length

    is not validated before the key is copied into a fixed-size buffer.

    III. Impact

    An attacker who can connect to the telnetd daemon can execute arbitrary

    code with the privileges of the daemon (which is usually the "root"

    superuser).

    Now, that I can understand. Pretty simple to patch really, unless I'm missing something. (also, ssh, d'uh)

  4. FordPrefect

    Who would still have there web and email security appliances managed via telnet? Even if telnet is enabled by default the first thing you do once you have an ip address on the thing is to create an SSH key, enable SSH, disable telnet and then change the password.

    1. Crazy Operations Guy

      Real network equipment should generate an ssh key on its own the first time its booted up (and before it turns on networking) and refuse connections from anything until you directly connect a serial cable to it and manually turn on remote management.

  5. Henry Wertz 1 Gold badge

    Learn something new every day

    I didn't know telnet had an encryption option either. I learn something every day 8-)

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like