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.

Comments

More info:

[laserjet]

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:

[Bob Dobbs]

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

Re:More info:

[Anonymous Coward]

login is flawed, not telnetd or rlogin.. 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).

Re:More info:

[pci]

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/

This IS, but, but ...

[wowbagger]

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.

Re:This IS, but, but ...

[Rob Y.]

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.

Buffer overflows are inexcusable in 2001

[po8]

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.

Re:Buffer overflows are inexcusable in 2001

[awptic]

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.

Re:Let me guess... (moderators, read this)

[HMC CS Major]

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.

/bin/login - ssh

[jullrich]

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

It's hard to exploit buffer overflows in Solaris..

[Dimwit]

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

[tribbel]

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

[The Mad Duke]

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

Re:'Another Gaping security hole goes unpatched?'

[0xdeadbeef]

But a patch is already available, as is information about the vulnerability.

Solaris Sparc kernel-level stack protection.

[Nonesuch]

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.

Re:It's hard to exploit buffer overflows in Solari

[polymath69]

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.

Another article from InfoWorld

[Vodalian]

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

Re:When can we banish Telnet forever?

[frantzdb]

Here at cs.hmc.edu we do just that. No telnet. Period. If you consider doing this to your system, I'd suggest making MindTerm available. It's a GPLed Java SSH terminal. With that, nobody can have any excuses.

--Ben

Already patched on FreeBSD...

[CoolVibe]

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.

Re:When can we banish Telnet forever?

[helixblue]

Luckilly, work on this has already been done. All of the open-source BSD's (NetBSD, FreeBSD, OpenBSD, and Darwin) as well as MacOS X 10.1 do not ship with ftp or telnet enabled by default. You must manually edit /etc/inetd.conf to shoot yourself in the foot.

There was much joy when they all decided to make this change over the last 18 months or so (not sure when OpenBSD did it).

I'd love to see Solaris 9 ship with OpenSSH, hopefully no pesky lawyers saying "But this country and their crypto!" will stop that from happening.

Every new machine deployed here not only has no cleartext protocols enabled, but only has ssh2. Sure, the end Oracle developers will scream cause they love their telnet app. But this is silly.

RISC CPU feature. (OT)

[CoolVibe]

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.

Telnet?

[Otter]

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.

Re:When can we banish Telnet forever?

[Xipy]

I would love to see a GPLed Java SSH terminal, but MindTerm is not one...

From the appgate.org page:

MindTerm is available free of charge for personal and non-commercial use. MindTerm may be licensed for commercial use for a fee

Re:I AM **SICK** OF STUPID BUFFER OVERFLOW HOLES!!

[RFC959]

Yeah, but I don't think it's quite as easy as you make it out to be, either. From Solaris 8's ld.so.1 manpage:

SECURITY
To prevent malicious dependency substitution or symbol interposition, some restrictions may apply to the evalua- tion of the dependencies of secure processes. The runtime linker categorizes a process as secure if the user is not a super-user, and either the real user and effective user identifiers are not equal, or the real group and effective group identifiers are not equal. See getuid(2), geteuid(2), getgid(2), and getegid(2).

In short, you can't just make "printf" equal "exec /sbin/sh" and run your favorite setuid root program with LD_PRELOAD set.