Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security Sun Microsystems Worms IT

Worm Exploiting Solaris Telnetd Vulnerability 164

Posted by Zonk from the beware-of-rotten-fruit dept.
MichaelSmith writes "Several news sites are reporting that a worm is starting to exploit the Solaris Telnet 0-day vulnerability. By adding simple text to the Telnet command, the system will skip asking for a username and password. If the systems are installed out of the box, they automatically come Telnet-enabled. 'The SANS Internet Storm Center, which monitors Internet threats, has noticed some increase in activity on the network port used by Solaris' telnet feature, according to an ISC blog posted on Tuesday. "One hopes that there aren't that many publicly reachable Solaris systems running telnet," ISC staffer Joel Esler wrote.'"
This discussion has been archived. No new comments can be posted.

Worm Exploiting Solaris Telnetd Vulnerability More

Worm Exploiting Solaris Telnetd Vulnerability

Comments Filter:

  • Yep. (Score:5, Insightful)

    by AltGrendel ( 175092 ) <`su.0tixe' `ta' `todhsals-ga'> on Friday March 02, 2007 @11:31AM (#18207766) Homepage
    That's one of the first things any good admin turns off.

    Use SSH.

    ...oh, and don't forget to wear your raincoat.

    • Re:Yep. (Score:5, Insightful)

      by fm6 ( 162816 ) on Friday March 02, 2007 @11:42AM (#18207892) Homepage Journal

      Yeah, that was my response when I first heard of this bug/exploit. But the real question is, should systems be shiped with telnet enabled? Obviously the answer is "no", but vendors seem to be slow to get this message.

      And note that this worm is enabled by a bug in Solaris's implementation of telnet, not by telnet itself. A similar bug in ssh would have had the same effect.

      • Re:Yep. (Score:4, Funny)

        by Venik ( 915777 ) on Friday March 02, 2007 @12:08PM (#18208146)
        I think the real question is: should Solaris telnetd have such an immense security hole?

        • Re: (Score:2)

          by fm6 ( 162816 )
          No, the real question is: should I pay attention to a post stating the obvious?

          • Re: (Score:2)

            by Venik ( 915777 )
            Well, I am glad you think it's obvious. I was beginning to worry about folks here criticizing sysadmins for having telnet running, as opposed to criticizing Sun for missing such an obvious hole in their OS.
            • Well, it's arguable that shipping telnetd at all even without this vulnerability is an obvious hole in the OS, but software bugs are usually only "obvious" after they've been found.

              • Re: (Score:3, Insightful)

                by Venik ( 915777 )
                There is nothing inherently wrong with telnet. It has functional limitations, just as any other method of communication. Telnet can be safely used, when its limitations are accounted in the overall environment. Look at it this way. A company that makes locks accidentally produced a model that can be opened by any key. Oops. You are saying: Hey, everybody knows that locks can be picked, so why are you still using them? Do you see a difference between a design limitation and a production defect?
                • This company sells houses, and installs this lock by default on the backdoor of every house it sells.

      • Re: (Score:3, Interesting)

        by ray-auch ( 454705 )
        But the real question is, should systems be shiped with telnet enabled? Obviously the answer is "no", but vendors seem to be slow to get this message.

        This is Sun. Remember "+" in hosts.equiv ? They deliberately shipped with a known insecure default config in order to reduce support costs / complaints ("ease-of-use" was allegedly considered more important than security).

        • Re: (Score:3, Insightful)

          by fm6 ( 162816 )
          Putting ease of use ahead of security is hardly unique to Sun. Actually, this kind of thing isn't even an ease of use issue. Somebody gets a customer complaint, they see a fix, and they implement it without thinking through the security implications. Happens every day — usually several times.

      • Yeah, that was my response when I first heard of this bug/exploit. But the real question is, should systems be shiped with telnet enabled? Obviously the answer is "no", but vendors seem to be slow to get this message.

        Serious questions: 1. Who ships with telnet enabled? Certainly not Apple or any of the Linux distros I've used. and 2. Who uses Unix systems with the default build installed by Sun? Do they even _come_ with an OS anymore?

      • Re: (Score:2)

        by G00F ( 241765 )
        "Yeah, that was my response when I first heard of this bug/exploit."

        Eh? My response was, who cares, no one uses it, but I'll check the top leevl comments to see if there was anything interesting or insightfull. I guess not ;)

        • Re: (Score:2)

          by fm6 ( 162816 )
          Typical Slashdotter provincialism. In the real world, "No one I know" != "No one". And I'm guessing you don't run a data center or anything like that. Probably the fanciest system you've ever seen is your big brother's game machine.

      • Re: (Score:3, Insightful)

        by pclminion ( 145572 )

        Yeah, that was my response when I first heard of this bug/exploit. But the real question is, should systems be shiped with telnet enabled? Obviously the answer is "no", but vendors seem to be slow to get this message.

        Why the hell not? Installation of Solaris is not exactly an "end user" type of operations. More likely it would be performed by an IT professional. Having telnet enabled initially makes it easy to setup the system from another location without worrying about making ssh or anything else work

        • Re: (Score:2)

          by fm6 ( 162816 )

          Having telnet enabled initially makes it easy to setup the system from another location without worrying about making ssh or anything else work.

          So the convenience of the admin is more important than the security of the system? Your logic is the reason security is such a problem. Besides, what's the big deal in "making ssh work"? I've never had any trouble.

          Incidentally, Solaris 11 will be shipped with all unnecessary services (including telnet) disabled by default.

          • So the convenience of the admin is more important than the security of the system?

            The security of the system is of FUNDAMENTAL importance. It is a failure of the administrator which turns telnet into a vulnerability. Security ultimately derives from actions taken by human beings. If humans don't do what is appropriate and security is compromised, it is the humans who have failed, not the system.

            • Re: (Score:2)

              by fm6 ( 162816 )
              Let me guess: you're a Republican, right? Keeping the system safe is less important than allowing the sysadmin to demonstrate his Moral Fiber. Jeees-us!

              Telnet is an obsolete protocol that nobody needs. If you want to show your "responsibility", take the trouble to learn how to use SSH. Or if you must use telnet, live with the fact that OS vendors are going to make you turn it on, instead of leaving an insecure protocol enabled by default.

    • Re: (Score:2)

      by Afecks ( 899057 )
      A good Windows admin has a router, firewall, anti-virus, automatic updates and a 3rd party browser. If that's not a good argument against the thousands of Windows zombies out there then it's not a good argument for you either.

    • Re:Yep. (Score:4, Insightful)

      by iamacat ( 583406 ) on Friday March 02, 2007 @12:24PM (#18208380)
      ssh is actually more complex than telnet and more likely to have exploitable bugs - there were a couple featured on slashdot in fact. ssh is for protection of the user, not the host system. It can make intrusion recovery more difficult, as you will not be able to see what the attacker is doing using network monitoring tools. Sun just got sloppy/unlucky with this one by unnecessarily mucking with login. Don't they teach in school to not add command line options/environment variables to a setuid program?

      • Exactly. All these comments to the effect of "telnetd should be off by default" are missing the point. Yes, telnetd should be off by default, but that's just so that dumb users don't get used to typing in their passwords over a cleartext connection.

        It makes me wonder about how much original thought there is on Slashdot, versus how many comments are just clueless people using technical terms in a syntactically-correct fashion without really understanding what they're saying.

        If I went back into the Slas

        • Re: (Score:2)

          by amper ( 33785 ) *
          What really makes me laugh is how many people think that running sshd instead of telnetd is somehow going to magically give you protection from being hacked.

          For those of you who don't realize this...you can break into *any* vanilla sshd by guessing the right password...just the same as if you were running telnetd. The *only* difference is somewhat greater protection over having your password sniffed over the network while in transit. Unless, of course, you're running some sort of PKI infrastructure with cli
          • - The Solaris telnet authenticates against their login PAM modules, which only uses the first 8 chars of the password for authentication. SSH bypasses /bin/login and passwords can be as long as you want. This is more longtime Solaris silliness that has not been fixed in Solaris 10.

            At least they do come with a binch of stuff disabled by default, and with a fairly recent version of SSH.

            I *DO* have numerous Solaris hosts happily floating in the effuent of an unfirewalled Internet connection, and they are probe
            • man crypt_bsdmd5

              in /etc/security/crypt.conf:
              CRYPT_DEFAULT=__unix__ => CRYPT_DEFAULT=1

              This makes Solaris PAM compatible with Linux/BSD-style MD5 shadow hashes distributed via file, NIS, LDAP, or whatever. It will process an arbitrarily long password.

              And in that case, you should edit your /etc/ssh/sshd_config and set PAMAuthenticationViaKBDInt to yes. That way you can manage your auth/session modules via pam.conf and manage your security policy in one place.
              • Actually I'm an idiot and don't deserve my mod point. BAD INFORMATION - I should have pointed out that Solaris passwd only uses the first 8 chars, and it's the bottleneck, unless you switch to MD5 as you suggest. So a password entered with passwd by default will only pay attention to the first 8 chars whether you are using telnet or ssh "out of the box".

                We use public key authentication, with passwords, and bypass password authentication completely, shoudl have said that.

                Oh well, won't be the first time I go

        • It makes me wonder about how much original thought there is on Slashdot, versus how many comments are just clueless people using technical terms in a syntactically-correct fashion without really understanding what they're saying.

          You must be new here.

          If I went back into the Slashdot archives for around 1999, I wouldn't be surprised if I could find a ton of comments to the effect of "only stupid people write down their passwords".

          That's because obvious truths == positive moderation. Inobvious truths and

      • ssh is actually more complex than telnet and more likely to have exploitable bugs - there were a couple featured on slashdot in fact. ssh is for protection of the user, not the host system. ssh is for protection of the user, not the host system.

        Keeping user accounts secure provides for the protection of the system. It's usually a lot easier to escalate from a local user to root than to simply get remote root.

        It can make intrusion recovery more difficult, as you will not be able to see what the attacker is

        • Re: (Score:2)

          by iamacat ( 583406 )
          So in the case you described, encryption would benefit you and not the owner of the system. Intruder could use a shell without a tty and ptrace his own processes so that you can not. It's much more reliable to log telnet traffic from an independent system that doesn't allow any remote access. If I need to give people accounts with potentially dangerous privileges for them to do work, I might prefer telnet so that, if someone "fucks once" with my database, I can discover who it was. If I am chatting with my

    • Correction (Score:3, Interesting)

      by Megane ( 129182 )

      Correction: that's one of the first things any good distro never turns on.

      Linux and BSD had it for a long time before Solaris had it in the standard install. And you can't even enable telnetd on OS X since about 10.2 or so, unless you know how to edit the right config files in /etc.

    • Most linux distros stopped enabling the telnet daemon post-install years ago. Now, however, even the big vendors like Redhat leave PermitRootLogin=yes in the config file for the ssh daemon which is nearly as bad. It's on my checklist as the first thing to fix post-install on new servers.

    • Re: (Score:2)

      by LWATCDR ( 28044 )
      Why have telnetd on the system at all?

      I kind of thought that ssh had replaced telnet a long time ago.
      Then again on a server maybe nothing should be turned on by default.

    • I have to admit to being amazed that telnetd is turned on at all in an installation of Solaris. In any Linux distro you have to enable it - heck, you usually have to do some digging for telnet and install it.

      I remember a couple years ago in my role as a Linux admin I had to help an outside vendor access a specialized Solaris box one of our research groups used, and they wanted telnet access to it. They were shocked (and remember, this was only a couple years ago) that my network team wouldn't put an exc

  • Oh no (Score:4, Funny)

    by wumpus188 ( 657540 ) on Friday March 02, 2007 @11:34AM (#18207796)
    These 4 users running telnet on solaris are gonna be pissed...

    • Re: (Score:2)

      by Degrees ( 220395 )
      After reading this [pbs.org], I wonder....

      (Nowhere does it say that the solaris servers are running telnet. But our IT organization has a connection to a state agency, and today the state agency warned us they had a virus on the rampage. That agency has one of those solaris servers running in one of our mini data centers.)

  • What about replacing telnetd with openbsd's?

    -uso.

    • Re: (Score:2, Informative)

      by ebvwfbw ( 864834 )
      What about replacing telnetd with openbsd's?

      It won't help because the vulnerability is in login (that telnetd calls) and not with telenetd. Since this is almost a month old and everyone should know by now, here it is -

      telnet -l "-froot" [hostname]

      • Re: (Score:2)

        by The Man ( 684 )
        No, that's not correct. login(1) is just fine; telnetd fails to correctly validate user input, passing arguments to login that it should not.

        Also, "Free software to the rescue" is rather misleading as well; the telnetd shipping in Solaris has been open source for almost 2 years. In any case, the bug has already been fixed and patches are available.

  • Mine is! (Score:3, Insightful)

    by Doctor Memory ( 6336 ) on Friday March 02, 2007 @11:37AM (#18207846)
    But it's only reachable via ports 80 and 443. And I installed patch #120069-02 a couple of weeks ago. In fact, I already installed the -03 version of that patch. If you keep up with your security patches, it's really not a problem. Of course, this is easy for me to say, I have one workstation; I'm sure that for sites with dozens (or hundreds) of servers, it's more problematic. I also STR that patch 120069 used to require a reboot after installation, which makes it a bit more of a hassle to install (I usually save those for Fridays, when I can install them and then walk away while the box reboots).
    • > I'm sure that for sites with dozens (or hundreds) of servers, it's more problematic

      Although in those cases I'd hope that they'd have everything nicely automated so that pushing out updates is just a matter running some utility that executes the update on all the machines. As Zed Shaw [zedshaw.com] says, "if you're ssh'ing in to your servers more than once a week, you haven't automated things enough."

      Of course there will be exceptions - custom installations and whatnot - but hopefully a change like this could just b

      • Re: (Score:2)

        by fm6 ( 162816 )

        As Zed Shaw [zedshaw.com] says, "if you're ssh'ing in to your servers more than once a week, you haven't automated things enough."

        Dude, many data centers have thousands of servers. Sun itself sells a blade system [sun.com] that puts 20 servers in a single rack. In that kind of environment, if you ever ssh into your systems, you haven't automated things enough!

        • Re: (Score:2)

          by amper ( 33785 ) *
          Not to nitpick, but did you mean 20 servers in a single rack space? Because if you didn't, 20 servers in a single, standard 42U rack isn't impressive, considering that with any ol' 1U server, you can fit 42 of them in the same space, right? OTOH, 20 servers in 1U *would* be impressive.

          • Re: (Score:2)

            by fm6 ( 162816 )
            Oops. You're quite correct. Though it should be noted that each of the blades in the system I mentioned is much more powerful than any 1U system.

        • Re: (Score:2)

          by drsmithy ( 35869 )

          Sun itself sells a blade system that puts 20 servers in a single rack.

          Sun's Blade system aren't particularly impressive from a density perspective - IBM's, with 14 blades per 7U (84 servers in a rack), are much more interesting.

      • Re: (Score:2)

        by msouth ( 10321 )

        > I'm sure that for sites with dozens (or hundreds) of servers, it's more problematic

        Although in those cases I'd hope that they'd have everything nicely automated so that pushing out updates is just a matter running some utility that executes the update on all the machines. As Zed Shaw says, "if you're ssh'ing in to your servers more than once a week, you haven't automated things enough."

        Uh, dude, I think the point is that they don't have to--we can just write a worm that installs the patch for them...

    • Re: (Score:2)

      by Nonac ( 132029 ) *
      > If you keep up with your security patches, it's really not a problem.

      I dare say that most sysadmins who keep up with patches don't have telnetd running.
    • I'm a sparc user so I don't have 120069, but 120068-03 "SunOS 5.10: in.telnetd patch" is listed as "Install Requirements: NA". Presumably these are the same patch. ...Interesting, -03 seems to fix 6524404 which says "rebootafter property is not necessary".

      Looks like -02 says it required a reboot but didn't; -03 does it right (I didn't get -02, I just disabled in.telnetd).

      -02 is quite hiliarious, it fixes bug "6523815 LARGE vulnerability in telnetd"

    • Re: (Score:2)

      by xsbellx ( 94649 )
      While I agree with the philosophy of of your post, the real world has a slightly different opinion. Let's take an example:

      1) You have 1200 Solaris production systems running various levels of Solaris, 7 through 10. You have an identical test environment, same 1200 severs running exactly the same version of everything. Add to this 700 odd UAT systems and about 500 dev systems. So now we are looking at 3600 servers. Now it's time to throw some bureaucracy into the mix.

      2) Patches must be TESTED in the dev

  • I might have missed something.... (Score:4, Informative)

    by 8127972 ( 73495 ) on Friday March 02, 2007 @11:38AM (#18207848)
    .... but wasn't this just fixed?

    http://blogs.sun.com/tpenta/entry/the_in_telnetd_v ulnerability_exploit [sun.com]
    • yes, but not everyone applies every patch the instant it becomes available.
      • Duh, you mean that sun doesn't have automatic software updates turned by default? It's a stupid thing to do, even for servers - and "admins must test the update first" is not an excuse, I'd rather have something breaking than a security hole

        • I'd rather have something breaking than a security hole
          I doubt you'll find many sysadmins agreeing with you there. As someone else mentioned, most sysadmins will already have disabled telnetd. So to install a patch and reboot their systems without warning (possibly during the work day) seems like a little harsh treatment for somebody who's already mitigated the threat.

        • Re: (Score:2)

          by boner ( 27505 )
          that is utterly stupid... you'd rather have an automatic update break your box so you can spend hours trying to find out how???

          For a reasonable commercial system downtime is measured in thousands of dollars of lost revenue per hour. You will want to update your post after you have had a CEO, CTO, CFO etc... throwing a hissy fit because the system is down... 'automatic update' as an excuse will get you fired, and rightly so.

        • Duh, you mean that sun doesn't have automatic software updates turned by default? It's a stupid thing to do, even for servers - and "admins must test the update first" is not an excuse, I'd rather have something breaking than a security hole
          In the real world, things need to be tested and run through the dev/stage/prod environments. This isn't Joe's Bait Shop we're talking about...
          • This isn't Joe's Bait Shop we're talking about...

            Which is why I wouldn't like to have a system that doesn't patches security holes ASAP.

            • This isn't Joe's Bait Shop we're talking about...

              Which is why I wouldn't like to have a system that doesn't patches security holes ASAP.
              Unless you can show me otherwise, I'm going with the statement made by several folks in the thread that it's disabled by default. It's only a security hole if you open it. If you cut a hole in the side of your house for when you leave, is that the house-builder's fault?

  • It's been a long day... (Score:5, Insightful)

    by Odiumjunkie ( 926074 ) on Friday March 02, 2007 @11:40AM (#18207868) Journal
    So, just to be clear, this story, posted on March 2nd, is reporting on a worm which has started exploiting a zero day vulnerability that was covered by slashdot on February 12th?

    Isn't twenty days long enough to disable a remotely exploitable and totally unnecessery, unsafe service that no admin in his right mind should have enabled on a box connected to the net anyway?

    • Re:It's been a long day... (Score:4, Funny)

      by Cheapy ( 809643 ) on Friday March 02, 2007 @11:43AM (#18207906)
      Sysadmins have been search this entire time to find a Solaris box to fix.

      They are still searching.

    • Re: (Score:2)

      by 8127972 ( 73495 )
      You must be new here.

    • Isn't twenty days long enough to disable a remotely exploitable and totally unnecessery, unsafe service that no admin in his right mind should have enabled on a box connected to the net anyway?

      Yes, but some people are a little slow... others are just overworked... and then there are the stupid ones...

      Honestly, does anybody have a use for telnet anymore? It really shouldn't be enabled by default anyway. I guess if your system isn't connected to the Internet you have no fears, but who would do that?

      • Re: (Score:2)

        by qwijibo ( 101731 )
        I work for a major bank that leaves telnet on all over the place, in spite of the 1997 company policy of replacing it with SSH as soon as possible. Sensible configuration and maintenance are impossible when business people micromanage the technology side. You'd think that putting a gun to their head would be enough to make people do it, but you'd be wrong. They're one step ahead of us all. Business people cannot be harmed by a bullet to the brain. They're already brain dead.

    • Re: (Score:3, Interesting)

      by dknj ( 441802 )
      Judging by your UID, i will assume you are new here and new to IT in general. In The Real World(tm), patches are not applied as soon as they are released. You must test them, most managers are clueless to OS level patches and require the same testing process that, say, application testing goes through. I have seen patches take a week to be approved and put into production and I have worked with companies that have a 30 day delayed patch release schedule.

      With that said, no one should be running any insecu

      • Re: (Score:2)

        by Nethead ( 1563 )
        Judging by your UID, I will assume you are new here.

        • Re: (Score:2)

          by dknj ( 441802 )
          no just a long time lurker. i should have a uid in the 5 digit range, but i always posted as AC. when i finally decided to register an account, it was already in the 400,000 range. similar with icq, k5, and audiworld

  • Should have happened... (Score:5, Insightful)

    by alexhs ( 877055 ) on Friday March 02, 2007 @11:47AM (#18207944) Homepage Journal
    What about this argument that OSs other than Microsoft ones don't get malware developped for them because they don't have significant marketshare, again ?
    • It's not just marketshare. Being easily exploited and high profile also need to fit the bill too. Do we ever hear about exploits for QNX, BeOS, OS/2, Minix, etc? At least we don't hear about them on slashdot.

      • Do we ever hear about exploits for QNX, BeOS, OS/2, Minix, etc? At least we don't hear about them on slashdot.
        Yeah, but to be exploited, you first need a network stack. Oh, and you'll need one to submit the story to slashdot too.
    • I was wondering how to spin this so that it would possibly be anti-Microsoft. Thank you, Slashdot.

  • telwhat? (Score:3, Funny)

    by glwtta ( 532858 ) on Friday March 02, 2007 @11:52AM (#18207980) Homepage
    Tell who?

    What year is it?

  • Other Telnet vulnerabilities (Score:3, Insightful)

    by Flying pig ( 925874 ) on Friday March 02, 2007 @11:52AM (#18207988)
    Amazing but true - there are printers on some networks which are accessible over the public Internet and which have their telnet ports exposed. I'm obviously not spelling out the implications here, but some people need the proverbial rocket up the backside.

  • Telnet for transparency? (Score:4, Interesting)

    by Anonymous Coward on Friday March 02, 2007 @11:53AM (#18207990)
    A while ago I found a strange comment here about why telnet was still used, even by security-knowledgeable IT department. The comment was saying this:

    Large financial institutions in Europe use telnet, as use of encryption is restricted on their trusted networks, for reasons of transparency to the stock regulating authorities. (Googling for this phrase should get you the /. comment)

    If this is true (and not the post of a random troll), can anyone shed some light on this? For it seems very strange... There are many other way to provide transparency to the financial authorities without having to compromise your network no!?

  • A new box won't have this problem... (Score:3, Insightful)

    by kenh ( 9056 ) on Friday March 02, 2007 @11:58AM (#18208034) Homepage Journal
    This is not present in the Update 3 of Solaris, released 11/06 - that prompts the user to enable "network services" if they like, but warns that will expose the system to problems. One of those problems is the famously insecure telnetd service. If you say "No" telnetd is not installed/activated - and "No" is the default.

    Existing boxes need to fix this, but a patch has been out for a while - are we dealing with the "short bus" hackers that it took this long to actually exploit? Why, oh why, doesn't Solaris warrant better hackers? ;^)
  • ...on writing the worlds most unsuccessful worm.

    isn't even coming close to their trend on activity-by-ports page
  • And is it going to take another 20 years to close all the holes in telnet?
  • At the university where I work, there were a number of people running Solaris boxes who weren't even aware that telnet was running. It's not that they weren't aware of the secure advantage of using SSH. But they just weren't paying close attention to what ports they had open.

    So if you or someone you know runs Solaris, but uses SSH, make sure that telnet is 100% disabled for sure!
  • I don't even run inetd!

  • Given the age of the vulnerability, it's probably just the Morris worm [wikipedia.org] still kicking about.
  • The last time I used telnet was probably somewhere in the late 90's. Since then I've been using ssh, like most people. Besides being secure, ssh puts a lot of power and flexibility at my fingertips: port-forwarding for tunnelling, passwordless connectivity, secure file transfers just to name a few. So it could be that it's been so long that I don't see the point of using telnet anymore, let alone willingly leave it enabled on my systems.

    So besides the old argument of "I have legacy systems / applications wh

    • Re: (Score:3, Informative)

      by 99BottlesOfBeerInMyF ( 813746 )

      So besides the old argument of "I have legacy systems / applications which rely on telnet and other outdated modes of communication", why would people use telnet? Laziness? Ignorance? What else am I missing here?

      People who use telnet on a large scale that I know of include:

      • European financial companies who are not allowed to use encryption while trading stock for regulatory reasons (on a private network).
      • South and Central American ISPs who provide shell accounts as part of internet access and who have to support the lowest common denominator.
      • Major network operators in Asia and China who run telnet on their control networks.
      • New hardware appliances that are configured once from telnet or console and for whom SSH
  • 'The SANS Internet Storm Center, which monitors Internet threats, has noticed some increase in activity on the network port used by Solaris' telnet feature, according to an ISC blog posted on Tuesday.

    Pardon my ignorance, but doesn't Solaris use TCP port 23 like every other version of telnet in the universe, unless it's specifically redirected to a different port?
  • I would have thought that by now nobody would be shipping systems with telnetd enabled by default.
  • Telnet is *not* enabled out-of-the-box.

    And, as has been noted, the patch has been available for about 3 weeks now.

    This is a terrible bug, which should never have got in to Solaris in the first place, but it did, and it was fixed.

    OTOH, if you've
    a) Chosen to run telnetd in the first place, and
    b) Explicitly enabled remote root login for maximum damange
    Then you can't really whine that "if a cracker can access the network, he can get root", because presumably "even if this bug did n

Slashdot Top Deals

The wages of sin are unreported.

Close