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

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.

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.

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

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.

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.

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.