Slashdot Mirror


Solaris, AIX Login Hole

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.

10 of 267 comments (clear)

  1. More info: by laserjet · · Score: 5, Informative


    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.

    --
    Moon Macrosystems. Sun's biggest competitor.
    1. Re:More info: by Bob+Dobbs · · Score: 5, Informative

      IBM already has emergency fixes available at ftp://aix.software.ibm.com/aix/efixes/security/tsm login_efix.tar.Z

  2. This IS, but, but ... by wowbagger · · Score: 4, Informative

    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.

  3. Buffer overflows are inexcusable in 2001 by po8 · · Score: 5, Informative

    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.
  4. /bin/login - ssh by jullrich · · Score: 5, Informative
    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

  5. It's hard to exploit buffer overflows in Solaris.. by Dimwit · · Score: 4, Informative

    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...

    --
    ...but it's being eaten...by some...Linux or something...
  6. IBM has an efix posted by The+Mad+Duke · · Score: 5, Informative

    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

    --
    -The Mad Duke
  7. Solaris Sparc kernel-level stack protection. by Nonesuch · · Score: 5, Informative
    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.

  8. Re:It's hard to exploit buffer overflows in Solari by polymath69 · · Score: 5, Informative

    Dang it, I was all set to moderate, but this needs a followup instead since Dimwit left something out. Namely that those set commands belong in /etc/system.

    --

    --
    I don't want to rule the world... I just want to be in charge of mayonnaise.
  9. Already patched on FreeBSD... by CoolVibe · · Score: 4, Informative
    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.