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:

[laserjet]

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:

[Bob Dobbs]

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

Let me guess...

[wiredog]

You can login as kt and get root.

The FBI is disappointed. . .

[Slicebo]

I guess that fixing this issue will delay delivery of "Magic Lantern for Unix" for a few months.

Re:See, Unix has problems too now.

[SirSlud]

> This is proof positive that MicroSoft make quality products. So now, can we all jsut lay off of MS and all decend in hordes on Sun and IBM?

Isn't this more like proof that *nix sucks as much as MS? ;)

Seirously tho, of course, the more mature techies will concede that both OS families have had their fair share of minor and major problems. I've never held either OS family up to such lofty 'uncrackable' standards, but the one thing I do have to say is that, considering MS's attitude towards its track record (ie, 'what me worry?'), it's still more frusterating when the exploit is an MS exploit rather than a Unix one.

Plus, much of the insecurity in Windows is due to the scripting and VB features that MS deemed so critical to the success of their software. This problem is an expoit, where as early email worms didn't even have to 'exploit' the box. MS's own feature set and technology caused billions of dollars in productivity loss in order to save the user from a few clicks, or incorperate 'gee wiz' functionality in their mail/www clients. That, to me, is far more damning than any accidental root exploit will ever be. Mistakes happen. Sacrificing security for brochure-ware is inexcusable and irresponsible.

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.

Another argument for open source

[b.foster]

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

[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

Re:See, Unix has problems too now.

[SuiteSisterMary]

unix holes are found VERY rarely

No, actually, it's just that all the holes in the commercial unixes were found ten years ago. But LORD were there a lot of them; X, rpc, lpr, bind, httpd, ftpd, rlogin, telnet, statd, fingerd, the list goes on and on and on.

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

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.

The RTM worm patch that just renamed the hole

[SimHacker]

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.

Sun et al aren't demanding silence, M$ is

[FreeUser]

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