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.
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.
You can login as kt and get root.
Best Slashdot Co
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.
www.eFax.com are spammers
I guess that fixing this issue will delay delivery of "Magic Lantern for Unix" for a few months.
Acutally it's been known for a long time that telnet and rlogin are insecure. The effort has been to shift people to secure methods such as OpenSSH for those things. For the most part any sysadmin that has been using telnet and rlogin is probably too lazy to switch. I worked under a sysadmin for a while and it took months of pushing to get him to start implemting SSH across the board.
--- I used to moderate, then I read the -1 articles and decided having to filter through them was not worth it.
Isn't this where Michael says:
'Another gaping security hole goes unpatched by Microsoft... Uh, I mean, er, Sun' ?
> 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.
"Old man yells at systemd"
There are at least 3 sure-fire solutions for eliminating all stack-overwriting buffer overflows in security-critical programs:
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:
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
For details, see the 'UseLogin' option in your sshd config file.
DShield.org... fight back
Vintage computer games and RPG books available. Email me if you're interested.
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...
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
I find it oddly tame that all michael has to say with this article is "There's a reuters story as well."
:)
He was able to expand into about 8 paragraphs with "Another Gaping Microsoft Security Hole Goes Unpatched."
When it is *nix, its "developer notice", and when it is win* it is "microsoft wants to rape us of our rights"?
I'm probably missing something, like 'duh, you shouldn't use telnet'. Then again, I actually believe the vapid notion that you'll be okay if you download from trusted sources, so I'm not worried about IE. I will save people the time and tell myself that there is no such thing as a trusted source
When?
...
I wish Unix/Linux would remove Telnet forever. Not just removed from default install, but removed from from the packages totally. If these things weren't installed by default, and people were forced to use ssh, we could come a long ways.
People are too lazy to use ssh instead of telnet. So, force them to use ssh. Even behind firewalls.
Old apps use telnet? Tough, if the company values security they'll convert. If not, they get the same sympathy that people who open unknown attachments get, none
Unbelievable! Anybody notice how clear, concise and FUD free this post by michael was? It seems only yesterday that we had a full page rant by michael himself that deplored Microsoft for not revealing a GAPING secutiry hole until recently.
Microsoft has known about it since November 19; they refuse to provide any information about when a patch might be made available, if ever.
Now lets see... "ISS discovered the loophole in October" Hmm.... that's a whole month longer than Mircosoft held out...
Netscape and most other browsers have no problem with this.
This is a *serious* security hole, and it's all sun's fault. Macintosh, Windows and most other operating systems don't have a problem with this.
If you routinely browse with Internet Explorer or read mail with Outlook, keep in mind that any web page you visit or any email you open can take over your computer, steal sensitive files, destroy your machine, anything.
If you routinely use Solaris or AIX to login and do work, keep in mind that anybody can take over your computer, steal sensitive files, destroy your machine, anything.
Happy browsing!
Congrats! You've got Gaping Security Hole!
Hmm.. maybe we can do with a little more balanced reporting here on bash-Microdot.org
With this in place, 'stack overflow' exploits don't execute.
I do not deploy Linux. Ever.
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.
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.
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.
What I'm listening to now on Pandora...
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:
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 /usr/lib/sendmail | egrep debug /usr/lib/sendmail
okeeffe:tmp {2} strings -o -a
0096972 debug
okeeffe:tmp {3} adb -w
?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.
Take a look and feel free: http://www.PieMenu.com
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.
The Future of Human Evolution: Autonomy
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...
as it has already been cracked
I remember one hillarious Sun security hole, around SunOS 3.0 or so, that let you get a root shell by walking up to the console and holding down one of they keys until it autorepeated enough to fill up a buffer somewhere. Then you just hit the return key and it logged you in with a root shell! Chris Torek, Mark Weiser, Steve Miller and I witnessed this behavior on Suns at the U of Maryland some time during the 80's.
My favorite boneheaded idiotic Unix security hole was the /etc/passwd "::0:0:::" bug.
It would conveniently open up a giant security hole whenever somebody accidentally left a blank line in /etc/passwd.
The next time anybody changed their password, the setuid root "passwd" program would read the old /etc/passwd file line by line using scanf("%s:%s:%d:%d:%s:%s:%s", ...), without checking for errors, then write out the new password file using printf("%s:%s:%d:%d:%s:%s:%s", ...). The blank line would read in as zero length strings and zeros, and would be written back out as "::0:0:::".
And of course what does "::0:0:::" mean in /etc/passwd? It defines a root-privileged user whose name is the null string! How convenient!
Then all anyone has to do to get root was to type:
% su ""
On the Pyramid (which ran a bizarre hybrid combination of BSD and System V), all you had to do to exploit this hole was to hit the return key at the "login:" prompt, and it would display the message of the day followed by the a root shell prompt "#".
People complain that Unix is difficult to use, and requires a lot of typing. But getting a root shell was certainly quite easy, requiring even fewer keystrokes on the Pyramid than the Sun.
Has Windows NT *EVER* been that easy and convenient to break into? I don't think so.
-Don
Take a look and feel free: http://www.PieMenu.com
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.
And a second followup that the whole thing is moot since that "fix" has been hacked.
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...