Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security

Solaris, AIX Login Hole 267

Posted by michael from the still-another-reason-not-to-use-telnet dept.
An anonymous submitter sent in: "A CERT Advisory describes a buffer overflow vulnerability in implementations of login derived from System V, which includes among Solaris 8 and earlier and AIX 4.3/5.1. "An exploit exists and may be circulating." Vendors are testing fixes." There's a Reuters story as well.
This discussion has been archived. No new comments can be posted.

Solaris, AIX Login Hole More

Solaris, AIX Login Hole

Comments Filter:

  • More info: (Score:5, Informative)

    by laserjet ( 170008 ) on Thursday December 13, 2001 @12:56PM (#2699710) Homepage

    here's the shake down for those to lazy to go to the site and read the article:

    The hole is located in the "login" program that allows people to sign on to the operating system remotely by entering a username and password, ISS said. The vulnerability can be exploited only if certain remote command protocols, such as Telnet, are enabled, which they usually are by default, the company said.

    ISS discovered the loophole in October and has been working with Sun and CERT on a fix, said Ingevaldson.

    "We're not aware of anyone experiencing a problem with this," said Sun spokesman Russ Castronovo.

    The security hole is very serious because there are so many computers in corporations and universities that run Solaris and because of the amount of harm someone could do if they were to gain complete control over a vulnerable machine, he said.

    "Once you have super-user access to a machine you can do anything you want, modify files, create them, sniff network traffic," Ingevaldson said.

    A temporary software patch is available for download from http://sunsolve.sun.com/securitypatch and a fully supported and tested fix will be available next week, Ingevaldson said.

    Fixes are pending for AIX, according to CERT.

    • Re:More info: (Score:3, Insightful)

      by well_jung ( 462688 )
      Really, if you are running rlogin or telnet, you have no reasonable expectationsof security. They all already known to be insecure.

      Of course, it never hurts to reinforce this.

      • Re:More info: (Score:5, Insightful)

        by laserjet ( 170008 ) on Thursday December 13, 2001 @01:20PM (#2699843) Homepage
        True, but ssh has been slow catch on, especially in large companies behind firewalls. what you point out, and they need to understand, is that most computer crime in a company occurs within the company. so, you may be effectively off the internet, but if you are using rlogin/telnet, you still have the potential of security threats.

        to the IT person, it would be a great pain to install ssh on thousands of machines, so to help this effort, i think it should be the responsibility of the server manufacturers to put forth the (small) effort and install ssh by defauly. why is this not being done? (exception that i know of is many linux distros install ssh by default. good for them).

        • Re:More info: (Score:2, Informative)

          by Anonymous Coward
          login is flawed, not telnetd or rlogin. [slashdot.org]. That means anything that calls login can be used to gain privileges. This includes SOME ssh implementations (those specifically choosing to call login rather than authenticate by themselves).
        • Yes and most major companies got infected with Code Red on their internal machines because they were to lazy to patch them.

          I wonder how long it will be before there is a malicious Unix worm that teaches them the same lesson with telnet.

        • Re:More info: (Score:2, Informative)

          by pci ( 13339 )
          If you work for a large company that likes using rlogin and telnetd, get them to switch to kerberos. It using the old commands (i.e. rcp, rsh, telnet, ftp, rlogin), but has updated them and includes single sign-on and encryption.
          That way you don't have to teach all your developers and administrators to type "ssh" instead of "telnet" which has been working for them for years.

          More information is at http://web.mit.edu/kerberos/www/
          • i wish i could... however i am sure you know how hard it would be to change a big huge company. nearly impossible. no, it would be impossible (at least from my shoes). the best i could hope for is to help the department i work for migrate to kerberos. It would take a policy change at the head IT level to make a real difference, I'm afraid, and that will not happen until there IS a major break-in or something. oh well!
      • rlogin and telnet are 'insecure' in that data transmitted over them is insecure; this is known.. and ssh2 is a good alternative.

        This buffer overflow bug is no different than those found in ssh previously...

        so saying that 'You shouldn't be running telnet' is bullshit.
        You shouldn't be USING telnet for anything you don't want sniffed is more accurate. Running it is only a problem in that it's yet one more available service.

    • Re:More info: (Score:5, Informative)

      by Bob Dobbs ( 21396 ) on Thursday December 13, 2001 @01:38PM (#2699947)
      IBM already has emergency fixes available at ftp://aix.software.ibm.com/aix/efixes/security/tsm login_efix.tar.Z
    • A temporary software patch is available for download from http://sunsolve.sun.com/securitypatch and a fully supported and tested fix will be available next week, Ingevaldson said.

      Either Ingevaldson needs to check his facts, or I'm going blind in my advanced age, because the patch ain't there.

      That takes you to the fully supported patches.

  • Let me guess... (Score:5, Funny)

    by wiredog ( 43288 ) on Thursday December 13, 2001 @01:00PM (#2699720) Journal
    You can login as kt [acm.org] and get root.
    • The above comment is not offtopic. The above comment refers to trojanning c compilers to put a back door into login programs. This was not only written about by Ken Thompson (linked in the article above), but successfully accomplished by a bastard of a programmer.

      Thus, the above comment is on topic, just over someone's head.

  • This IS, but, but ... (Score:4, Informative)

    by wowbagger ( 69688 ) on Thursday December 13, 2001 @01:04PM (#2699746) Homepage Journal
    This is a bad vulnerability, but not awful - you have to be allowing Telnet or RLogin access to the server for this exploit to be at risk.

    Since Telnet and Rlogin are insecure by design, they should only be allowed to be used in environments where you implicitly trust all parties. You should never deploy them where bad guys can get ahold of them - in those cases you should use (open)SSH.
    • Even using SSH, users with valid accounts can use the login command to exploit this once they're SSH'd in.

      SSH helps, but isn't a complete solution to command-line vulnerabilities.
    • Since Telnet and Rlogin are insecure by design, they should only be allowed to be used in environments where you implicitly trust all parties.
      What "parties" are you talking about exactly? I assume you mean the network infrastructure between the client and the server? Telnet and rlogin are susceptible to network-level attacks: someone sniffs a password off the wire, or someone launches a man-in-the-middle attack to insert some commands into the telnet stream or something.

      If I only telnet over networking infrastructure I trust (e.g., there are secured switches on both ends, I trust that my ISP hasn't been hacked, etc.), then I am safe. All users must authenticate with passwords to gain access. With these holes, anyone can remotely log in as root. Yeah, telnet/rlogin/rsh might not be as secure as ssh, but they're no where near the category of vulnerability that this hole exposes.

  • The FBI is disappointed. . . (Score:5, Funny)

    by Slicebo ( 221580 ) on Thursday December 13, 2001 @01:05PM (#2699754)
    I guess that fixing this issue will delay delivery of "Magic Lantern for Unix" for a few months.

  • 'Another Gaping security hole goes unpatched?' (Score:3, Funny)

    by Anonymous Coward on Thursday December 13, 2001 @01:08PM (#2699775)
    Isn't this where Michael says:
    'Another gaping security hole goes unpatched by Microsoft... Uh, I mean, er, Sun' ?
    • But a patch is already available, as is information about the vulnerability.
      • If you reads the vulnerability page at http://www.kb.cert.org/vuls/id/569272 [cert.org] you'll see it has taken 7 weeks from the first vendor response to the vulnerability, to the last one (the last being Sun, yesterday).

        You will also see the comment: "An exploit exists and may be circulating.". This means that CERT and Sun have sat on this vulnerability for well over a month without telling anyone about the problem, despite an exploit being in use.

        The story 2 days ago about Microsoft security was about a problem Microsoft had known about for 4 weeks (reported to them on Nov 19th).

        Finally, the patch is available for IBM's AIX 4.3.3 and 5.2, but not as far as I can tell for Solaris 8.

        However much you blindly hate Microsoft, they are not as bad as Sun in this particular situation.
    • And they knew about this since October. Sheesh.... this is just typical non-disclosure tactics. I bet they just couldnt be bothered to fix it, so they didnt tell anyone. This is an impingement on my basic freedom and right to fix security loopholes on my own box.

  • Buffer overflows are inexcusable in 2001 (Score:5, Informative)

    by po8 ( 187055 ) on Thursday December 13, 2001 @01:11PM (#2699789)

    There are at least 3 sure-fire solutions for eliminating all stack-overwriting buffer overflows in security-critical programs:

    1. Write the programs in a programming language which automatically allocates memory.
    2. Formally prove the buffer usage of the programs to be safe.
    3. Use a C compilation/linking system which guarantees that memory cannot be overwritten.

    None of these solutions (except maybe #1) are easy, but none of them are beyond the state of the art, either. Given this, I find it inexcusable that these buffer overflows keep popping up.

    IMHO the rules are simple:

    • If you want your program to have privilege, use development techniques that ensure its security.
    • It is not OK to trust legacy C programs to be secure: they are full of security holes until proven otherwise.

    • Solaris Sparc kernel-level stack protection. (Score:5, Informative)

      by Nonesuch ( 90847 ) on Thursday December 13, 2001 @01:34PM (#2699924) Homepage Journal
      Solaris (on Sparc) has the ability to block execution of code on the stack:
      $ grep stack /etc/system

      set noexec_user_stack = 1
      set noexec_user_stack_log = 1

      With this in place, 'stack overflow' exploits don't execute.

      • RISC CPU feature. (OT) (Score:2, Informative)

        by CoolVibe ( 11466 )
        This is actually a feature of the SPARC processor. Actually, all RISC processors can do it. It involves being able to mark pages like the stack as non-executable (for storage only). This means that such a thing could also be done on PPC based CPU's. Of the OS must support it :-)

        Of course making the stack executable is not a miracle cure. You can still execute arbitrary code through another trampoline (like jumping into libc, rewriting/patching functions through trojaned libraries ($LD_LIBRARY_PATH and $LD_PRELOAD for example) or other tricks).

        Sorry if this is a little offtopic, but stack smashes aren't the only way to skin a cat.

      • That's not enough... (Score:3, Interesting)

        by flynn_nrg ( 266463 )
        as it has already been cracked [decepticons.org]

      • Re:Solaris Sparc kernel-level stack protection. (Score:4, Insightful)

        by btellier ( 126120 ) <btellier.gmail@com> on Thursday December 13, 2001 @04:28PM (#2701040)
        This type of protection is AT BEST a 5 minute detour for anyone who knows what they're doing. All this means is that if you overflow a buffer on the stack you can't return into a buffer on the stack. Meanwhile, this is virtually worthless, particularly in a local exploit, because you can still execute code on the heap. For instance, i overflow the stack on x86 linux and overwrite EIP to point into the environment variables on the heap. If i've put my shellcode into say $HOME it'll execute it without a problem.

        Also this does nothing to prevent heap overflows, which are often just as bad. If you'll remember the recent TSig bug in BIND 8 it exploited an off-by-one heap overflow which would in no way be stopped by this non-exec stack flag. The best prevention i've seen are using so-called "canary" values in between static buffers and saved return addresses, i.e. www.immunix.org
    • I've been on about this for a while now. Basically the number of C programmers who think they can avoid buffer overflows greatly outnumbers the number of C programmers who actually can. it's just too easy to make a mistake in that language. C++ is a bit better but a lot of C++ programmers are just programming C with operator overloading and will continue to use the primative data types and they will continue to make the same mistakes.

      While one might argue that an intrepreted language like Java could still have problems and might still be succeptable to buffer overflows due to buggy intrepreters, the fact of the matter is that it is much less likely that a server written in Java will ever lead to a root compromise. I counter that those arguments promote the fallacy that since perfect security is impossible, one should be willing to accept the current completely insecure status quo.

      I find it odd that many people take it as a personal insult when you suggest that various servers be coded in a language that makes it much harder to make a fatal mistake. It's pretty obvious that C's a security exposure and it's pretty obvious that C programmers will continue to make the kind of fatal mistakes that cause root exploits. Must we continue to take chances with our systems out of a misplaced loyalty to an aging language?

    • You're talking as if login was written last year. That's obviously not the case.

      The RISKS of replacing existing code wholesale with new code that conforms to your idea of good practice are obvious.
    • I also know three ways to avoid buffer overflow, and they don't require any of the techniques you mention. Two are easy, one is tedious, but not difficult:

      1) NEVER use

      char *gets(char *s);

      in a program. Use

      char *fgets(char *s, int n, FILE *stream);

      2) Use one of the kernel patches that renders the
      stack non-executable. Then, even if the bad
      guys manage to overflow a buffer, they can't
      do anything with it.

      3) Write your own low-level character-by-character
      i/o handlers that stop accepting input before
      the buffer overflows (that's the easy way), or
      reallocates the buffer to be larger (that's the
      more user-friendly way.

      Numbers 1 and 2 aren't difficult at all, number 3 can be VERY tedious, but it isn't difficult.
      • Number 3 is done; no need to implement it yourself.

        See: http://www.linux.com/howto/Secure-Programs-HOWTO/l ibrary-c.html [linux.com]

      • number three is not really something I directly agree with. Why? Because you end up with n to the power of n implementations of [insert unsafe library call], which is BAD (tm). Another problem is buffers of which the size is not exactly known, these have to be malloc()'ed or allocated otherwise.

        You are also forgetting that there are other ways to skin that cat. Rewriting functions, returning into libc or rewriting GOT entries are another way to wreak havoc.

        There's only one thing that really works: Code Reviews. Heck, programmers are human, they can slip up and make mistakes, even if they are the most careful coders in the world (they are still human). More eyeballs catch more bugs. And the next random person can spot a problem in five minutes that you are trying for days to prevent.

        Bugs happen. Deal with it. The advantage that we open source people have is that our code is open for peer review to a LOT of people, so these problems can be patched almost immediately.

    • Although I agree with you in some respect, most buffer overflows ca easily be blamed just as much on laziness on the programmers behalf, strncpy, snprintf, strncat, etc. have all been a part of standard C libraries for some time now, gcc even warns against the use of some of the non-limiting variants of these. It doesn't even take that much effort to check over a program and ensure anywhere data can be read from an external source (i.e. stdin, command line, socket, etc.) that it's allocating enough buffer space to hold the maximum allowed input. Checking for format string exploits is also trival, greping through the source tree for "printf" and ensuring you use a format string rather than passing a buffer directly is trivial. That covers the simplest of exploits anyways, as for other ones such as the recent wu-ftpd bug... that was just bad coding, especially in such a widely used daemon, the code should have been completely rewritten long ago seeing as it has a long history of problems.
  • This affects systems with telnet or rlogin accessible from the Internet? The implication is that these were somehow not vulnerable without this buffer overrun.
    News to me.

  • Another argument for open source (Score:5, Interesting)

    by b.foster ( 543648 ) on Thursday December 13, 2001 @01:15PM (#2699816)
    I am a part-time Solaris administrator who has several machines that are affected by this flaw. When I read about it on BUGTRAQ yesterday, I went to the "free Solaris" download page, grabbed the source tree, and patched and rebuilt my version of /bin/login. The whole process took about half an hour (excluding download time).

    But I am not an "average administrator." Months ago, I faxed Sun a really long contract that gave me the right to download their source distribution. This was a major PITA but I needed to modify some other parts of the OS at the time, so I had no choice.

    I simply cannot believe that Sun is taking over two months to patch this very simple problem. It's an unchecked buffer, for God's sake. Most C coders can fix a problem like this in their sleep.

    And that is why I believe that open source has a future and Sun does not. Regardless of what your stance is on the "many eyes makes all problems shallow" doctrine, it is beyond debate that fixing this sort of bug in Linux is extremely easy for the average C programmer. Unfortunately, that programmer may not have signed Sun's NDAs and sold their soul, and they would not have the source access that it takes to protect their machines.

    I really wish I could post my patch here, but that is a violation of my NDA. Sun's absolutist stance on intellectual property may sell them a lot of copies of Solaris, but it leaves us administrators exposed and looking stupid. My group will be moving to Linux as soon as all of our applications are available for it, and we will be giving Sun the boot. The nicer machines and OS just aren't worth the risk of getting rooted.

    Bill

  • /bin/login - ssh (Score:5, Informative)

    by jullrich ( 159167 ) on Thursday December 13, 2001 @01:16PM (#2699821) Homepage
    Even if you only run ssh, you may be vulnerable if you use /bin/login to verify logins.

    For details, see the 'UseLogin' option in your sshd config file.


    DShield.org... fight back [dshield.org]

    • Most, but not all, SSH installations have it turned off.

      man sshd

      UseLogin defaults to "no" -- so unless you have

      UseLogin yes

      in sshd_config, then you don't have a problem.

  • It's hard to exploit buffer overflows in Solaris.. (Score:4, Informative)

    by Dimwit ( 36756 ) on Thursday December 13, 2001 @01:17PM (#2699826)
    Most modern Unices (I know firsthand for Solaris and FreeBSD) allow you to disable execution of the stack. In fact, on Solaris, any attempt to execute the stack is logged.

    The inability to execute is enabled by default in Solaris 8. Logging is not. However, you can explicity enable both by entering:

    set noexec_user_stack=1
    set noexec_user_stack_log=1

    and rebooting. Not a huge deal. For FreeBSD, read the 'sysctl' man page.

    Besides, if you're running telnet, you're just asking to get hax0red...

  • yay for CERT (Score:2, Informative)

    by tribbel ( 103363 )

    It does make me wonder why the people at CERT don't ever pretend to be skript kiddies. I just found this little tid-bit on a well known site which serves a lot of exploits.

    Description: A "feature" of most telnetd programs is that they will pass environmental variables (like TERM, DISPLAY, etc) for you. Unfortunately this can be a problem if someone passes LD_PRELOAD and causes /bin/login to load trojan libraries!

    Author: Well known, squidge (squidge@onyx.infonexus.com) wrote this, but I doubt you can reach him. Isn't he in jail now?

    Compromise: root REMOTELY!

    Vulnerable Systems: Older Linux boxes, I think SunOS systems, probably others.

    Date: January 1996 maybe? Quite old but lives forever like phf.

  • IBM has an efix posted (Score:5, Informative)

    by The Mad Duke ( 222354 ) on Thursday December 13, 2001 @01:21PM (#2699848)
    IBM has a fix available for AIX 4.3 and 5.1 - download at ftp://service.boulder.ibm.com/aix/efixes/security/ tsmlogin_efix.tar.Z
    The tsm/login/getty program runs setuid root under AIX, this may be an increased vulnerability. Patch, patch, patch!
    - The Mad Duke
    • If you wonder about AIX 4.2: It's vulnerable, too. but IBM probably won't bother to publish a fix.

      Not mentioning unsupported, vulnerable versions in security advisories is probably not a good idea.

  • Oddly Tame vs. Zealously MS-Hating (Score:3, Insightful)

    by pOs*x ( 254850 ) on Thursday December 13, 2001 @01:25PM (#2699874)
    I find it oddly tame that all michael has to say with this article is "There's a reuters story as well."

    He was able to expand into about 8 paragraphs with "Another Gaping Microsoft Security Hole Goes Unpatched."

    When it is *nix, its "developer notice", and when it is win* it is "microsoft wants to rape us of our rights"?

    I'm probably missing something, like 'duh, you shouldn't use telnet'. Then again, I actually believe the vapid notion that you'll be okay if you download from trusted sources, so I'm not worried about IE. I will save people the time and tell myself that there is no such thing as a trusted source :)

    • Yeah, a more condemming story title, as far as Sun is concerned, would be to accuse them of being as sloppy and arrogant as MS.

      OTOH, if the markets and positions of Sun and MS were reversed I would expect Bill Gates and Scott McNealy to be able to instantaneously play the reverse roles without so ever as missing a single beat.


    • While I think you're correct that Slashdot is generally more tolerant of Unix problems than MS problems, there is some legitimacy. We see critical security problems fairly rarely from the major Unix players and we see them more often from MS. Also, the Unix players tend to get patches out a bit more quickly. Sun and IBM have temp. patches out which probably means they have a bunch of guys using the patch and banging on it mercilessly to see if they can break it. When they determine it's not breaking, they'll call the temp patch the patch.

      Entirely fair? No. Somewhat fair? Probably.

  • When can we banish Telnet forever? (Score:3, Insightful)

    by reaper20 ( 23396 ) on Thursday December 13, 2001 @01:25PM (#2699876) Homepage
    When?

    I wish Unix/Linux would remove Telnet forever. Not just removed from default install, but removed from from the packages totally. If these things weren't installed by default, and people were forced to use ssh, we could come a long ways.

    People are too lazy to use ssh instead of telnet. So, force them to use ssh. Even behind firewalls.

    Old apps use telnet? Tough, if the company values security they'll convert. If not, they get the same sympathy that people who open unknown attachments get, none ...

  • Since michael won't do it (Score:4, Insightful)

    by edibleplastic ( 98111 ) on Thursday December 13, 2001 @01:30PM (#2699901)
    here's your FUD for this one.

    Unbelievable! Anybody notice how clear, concise and FUD free this post by michael was? It seems only yesterday that we had a full page rant by michael himself that deplored Microsoft for not revealing a GAPING secutiry hole until recently.


    Microsoft has known about it since November 19; they refuse to provide any information about when a patch might be made available, if ever.


    Now lets see... "ISS discovered the loophole in October" Hmm.... that's a whole month longer than Mircosoft held out...


    Netscape and most other browsers have no problem with this.


    This is a *serious* security hole, and it's all sun's fault. Macintosh, Windows and most other operating systems don't have a problem with this.


    If you routinely browse with Internet Explorer or read mail with Outlook, keep in mind that any web page you visit or any email you open can take over your computer, steal sensitive files, destroy your machine, anything.


    If you routinely use Solaris or AIX to login and do work, keep in mind that anybody can take over your computer, steal sensitive files, destroy your machine, anything.


    Happy browsing!


    Congrats! You've got Gaping Security Hole!


    Hmm.. maybe we can do with a little more balanced reporting here on bash-Microdot.org

    • Sun et al aren't demanding silence, M$ is (Score:5, Flamebait)

      by FreeUser ( 11483 ) on Thursday December 13, 2001 @02:01PM (#2700072)
      Sun et al aren't demanding silence from security professionals who discover bugs, security holes, and exploits.

      Microsoft is.

      What is more, Microsoft is trying to bribe [theregister.co.uk] security professionals and services into silence, requiring among other things that Microsoft be informed of problems before the securty firm's own paying customers are.

      In short, Sun & Co. have done nothing improper or worthy of customer or professional outrage.

      Microsoft has.

      Biased or not, Slashdot and its readership are more than a little correct in bashing Microsoft's security policies, and in reporting security lapses of other firms as well, even though these other firms have behaved in a much more ethical and open manner.

      Had it been otherwise, you doubtless would have been bashing slashdot and its readership for not reporting the vulnerabilities.

      In short, Mr. Microsoft Flunky, get over yourself. If slashdot's pro-Free Software and pro-GNU/Linux bias upsets you so much, then go hang out in a pro-Microsoft forum where you can suck up as much Redmond marketing drivel as your heart desires, while leaving the rest of us in peace.
      • The focus on Free Software is fine. Bashing MS is fine. Plenty to bash.

        But why not put it somewhere other than the front page article? Why not make the front page article concise, and let the rants come from others in the comments? Everyone can take their secret glee at the pains of MS, but when it's pointed out on the front page, it makes you sound insecure about your operating system's virtues. It's mudslinging.

        After all, Linux isn't better because MS sucks, it's better because it's better.
    • At least Sun and IBM are admitting that the hole exists. Plus, IBM already has a fix out.
      • "...keep in mind that anybody can take over your computer, steal sensitive files, destroy your machine, anything..."

      You don't have a f*cking clue.

      This is from CERT [cert.org]:

      • "...Several implementations of login that are derived from System V allow a user to specify arguments such as environment variables to the process. An array of buffers is used to store these arguments. A flaw exists in the checking of the number of arguments accepted. This flaw permits the array of buffers to be overflowed."

      That does not at all translate into "anybody can take over your computer, steal sensitive files, destroy your machine, anything"

      Go back to Redmond, M$ whore.

      t_t_b

      • Actually buffer overflows like this are exactly how people "take over your computer, steal sensitive files, destroy your machine, anything". The ability for a remote fucktard to get remote access to your machine is always a bad thing, whether it's a remote root exploit or not.
    • "This is a *serious* security hole, and it's all sun's fault"


      Last I checked, AIX is only sold by IBM. So there is a problem in the code of both of the two major "big iron" players OS's.

  • I submitted this URL from InfoWorld as well, but I guess the AC beat me too it. Look for it here [infoworld.com].

  • Already patched on FreeBSD... (Score:4, Informative)

    by CoolVibe ( 11466 ) on Thursday December 13, 2001 @01:44PM (#2699973) Journal
    Check the cvs-all@freebsd.org mailinglist for more info (the actual commit log is there). Oh. don't forget to mergemaster(1) after you build world, since this is also a configuration issue. Another fix was put in that prevents env variables to be passed on to login(1), which also helps in fixing this.

    Of course, correct me when I'm wrong or off base on this here... I don't know about any Solaris patches or AIX fixes, since I don't generally use those platforms, but I bet they are either underway. See your local sunsolve outlet or your IBM patch repository.

  • Telnet? (Score:3, Informative)

    by Otter ( 3800 ) on Thursday December 13, 2001 @01:55PM (#2700036) Journal
    Maybe I'm missing something here but it seems like everyone complaining about telnet is missing the point. Yeah, telnet is insecure in its own right but the issue here is a vulnerability in login:
    This vulnerability can be remotely exploited to gain privileges of the invoker of login. In the case of a program such as telnetd, rlogind, or other suid root programs, root access is gained.
    If the ssh server is configured the way a telnet server is (I'm guessing it is, although I could well be wrong since I've never run one) ssh would give you an identical vulnerability.

    I think I could have resisted throwing in a jab about people who know three or four factoids about security deciding that this story must involve one of those three or four things if Michael himself hadn't jumped on the anti-telnet bandwagon. Of course, I'm also wondering why the FUD-packed rant he directed at Microsoft a couple of days ago wasn't thought be newsworthy here. This is a much more serious hole and much easier to exploit against an alert target.

  • The RTM worm patch that just renamed the hole (Score:5, Interesting)

    by SimHacker ( 180785 ) on Thursday December 13, 2001 @01:56PM (#2700037) Homepage Journal
    Don't just install the first security patch that comes across the net, and assume you're safe.

    The day after Robert T Morris unleashed his worm on the internet on November 2, 1988, Keith Baaaaaaaahstic distributed instructions from the "Experimental Computing Facility, Center for Disease Control" on how to patch the sendmail binary by replacing the "D" in the "DEBUG" command with a null, thus disabling the worm.

    Unfortunately the effect was actually to change the name of the "DEBUG" command to the null string! So telnetting to port 25 and simply hitting CR to send a blank line would actually put sendmail into debug mode!

    Of course Sun Microsystems immediately installed this bogus patch, which I accidentally discovered, and reported to Sun. More than a year later I discussed it on the security mailing list... I hope that gave them enough time to fix the bug in the source code and recompile.

    -Don

    ====

    Date: Sun, 11 Feb 90 01:02:15 -0500
    From: don@cs.umd.edu (Don Hopkins)
    Subject: Computer Abuse / Product Liability / Criminal Statutes / ECPA
    To: blackcat@neuro.usc.edu
    Cc: security@pyrite.rutgers.edu

    >> [...] updating the old X10 server for the ibm/pc to work with X11R4, etc.

    Yeah, right. Might as well have them fill in the Grand Canyon using a pair of tweezers. How about having Robert Morris implement the Gnu kernel? I'm sure he's bright enough to come up with a very secure system (much to rms's disgust). So secure that only he would know the loopholes.

    Morris would be dead meat if his daddy didn't work for the NSA.

    One of the first patches for sendmail that was sent around to keep the Internet worm out was to edit the sendmail binary changing the 'D' in "DEBUG" to '\0', so the DEBUG command wouldn't work any more. Well that stopped the worm, but it made the null string invoke the debug command. I noticed this a couple days after the worm, when I telneted to sun.com port 25, to EXPN a user name of somebody on a mailing list I run, hit CR a couple of times to make sure sendmail was listening, and did the EXPN. It spit back huge ammounts of debugging information! Of course I promptly notified the appropriate people at Sun so they could put the right fix in. Sheez.

    -Don

    ====

    Date: 3 Nov 88 10:54:57 GMT
    From: bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
    Subject: Fixes for the virus
    Approved: ucb-fixes@okeeffe.berkeley.edu
    Subject: Fixes for the virus
    Index: usr.lib/sendmail/src/srvrsmtp.c 4BSD

    There's a virus running around; the salient facts. A bug in sendmail has been used to introduce a virus into a lot of Internet UNIX systems. It has not been observed to damage the host system, however, it's incredibly virulent, attempting to introduce itself to every system it can find. It appears to use rsh, broken passwords, and sendmail to introduce itself into the target systems. It affects only VAXen and Suns, as far as we know.

    There are three changes that we believe will immunize your system. They are attached.

    Thanks to the Experimental Computing Facility, Center for Disease Control for their assistance. (It's pretty late, and they certainly deserved some thanks, somewhere!)

    Fix:
    [...]

    If you don't have source, apply the following patch to your sendmail binary. SAVE A COPY OF IT FIRST, IN CASE YOU MESS UP! This is mildly tricky -- note, some versions of strings(1), which we're going to use to find the offset of the string "debug" in the binary print out the offsets in octal, not decimal. Run the following shell line to decide how your version of strings(1) works:

    /bin/echo 'abcd' | /usr/ucb/strings -o

    Note, make sure the eight control 'G's are preserved in this line. If this command results in something like:

    0000008 abcd

    your strings(1) command prints out locations in decimal, else it's octal.

    The patch script for sendmail. NOTE, YOUR OFFSETS MAY VARY!! This script assumes that your strings(1) command prints out the offsets in decimal.

    Script started on Thu Nov 3 02:08:14 1988
    okeeffe:tmp {2} strings -o -a /usr/lib/sendmail | egrep debug
    0096972 debug
    okeeffe:tmp {3} adb -w /usr/lib/sendmail
    ?m 0 0xffffffff 0
    0t10$d
    radix=10 base ten
    96972?s
    96972: debug
    96972?w 0
    96972: 25701 = 0
    okeeffe:tmp {4} ^D
    script done on Thu Nov 3 02:09:31 1988

    If your strings(1) command prints out the offsets in octal, change the line "0t10$d" to "0t8$d".

    After you've fixed sendmail, move both /bin/cc and /bin/ld to something else. (The virus uses the cc and the ld commands to rebuild itself to run on your system.)

    Finally, kill any processes on your system that don't belong there. Suspicious ones have "(sh)" or "xNNNNNNN" where the N's are random digits, as the command name on the ps(1) output line.

    One more thing, if you find files in /tmp or /usr/tmp that have names like "xNNNNNN,l1.c", or "xNNNNNN,sun3.o", or "xNNNNNNN,vax.o" where the N's are random digits, you've been infected.

    ====
    Keith sent out the following addendum to the patch, which prevents the null string bug, but Sun obviously didn't pay attention to it.
    ====

    Date: 3 Nov 88 16:12:19 GMT
    From: bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
    Subject: Fixes for the virus, #2
    Approved: ucb-fixes@okeeffe.berkeley.edu
    Original-newsgroup: comp.bugs.4bsd.ucb-fixes
    Index: usr.lib/sendmail/src/srvrsmtp.c 4BSD

    Description:

    This is a followup message, to clear up two points. First off, a better value to use to PATCH your sendmail executable is 0xff; if you're using the patch script, change:

    96972?w 0

    to:

    96972?w 65535

    Secondly, note, if, when you run strings(1) on your sendmail executable, greping for ``debug'', you don't get any output, don't worry about the problem, your system is already (we think) safe.

Slashdot Top Deals

The wages of sin are unreported.

Close