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

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

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.

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.

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

[Anonymous Coward]

how about when sun silenced people wrt to the problems caused by not having ecc on the cache on their SPARC chips? the idea that their above doing the same thing in this situation is nonsense.

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

[CoolVibe]

Uhm, this is not just buffer overflow material. Let me explain why:

You can set $LD_LIBRARY_PATH and $LD_PRELOAD.

How is this relevant?

Say, /bin/login uses a few common library calls, like say strcpy(3), right? Or better yet, getpasswd(3), or crypt(3).

Now, If I create a library with replacement versions of those calls that say, spawn a root shell, and can preload it before /bin/login loads the calls from libc, I'm set. Hey, instant root shell, without writing even a single line of buffer overflow code. How you get your trojan lib on the victim box is an excersize for the reader :-)

So, what if they _did_ use strncpy(3)? Well, I create my replacement function for that as well, big deal. What calls you use doesn't really matter...

I agree in that buffer overflows are inexcusable, but holes like this are to be frowned upon as well...

blah

[Anonymous Coward]

"An exploit exists and may be circulating."

Well, I'd say so. 30 seconds of searching on google revealed the exploit with a really good explanation of the problem and solutions to protect yourself. As well as an OpenSSH exploit.

From the file:
HOW TO PROTECT: There are a few ways. If you have a statically linked login, then you are safe. setuid programs ignore LD_PRELOAD so one you have logged in, you cannot subvert the system.

You can patch telnetd to wipe all but a few env variables. There are many widely pieces of available code to demonstrate this.

That's not enough...

[flynn_nrg]

as it has already been cracked

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

[CoolVibe]

For instance: gdkxft, the program that provides AA fonts for GTK apps uses this technique too. This way, you don't have to patch and recompile the complete GTK lib. Instead you just overload existing functions, and viola, GTK has AA fonts, no recompile of GTK required.

It has its prositive uses and can be a timesaver if you need to test stuff out, but it's also a big security hazard if you're not careful...