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.
> 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"
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).
Moon Macrosystems. Sun's biggest competitor.
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
Does not affect things like
telnet locis.loc.gov
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
This type of protection is AT BEST a 5 minute detour for anyone who knows what they're doing. All this means is that if you overflow a buffer on the stack you can't return into a buffer on the stack. Meanwhile, this is virtually worthless, particularly in a local exploit, because you can still execute code on the heap. For instance, i overflow the stack on x86 linux and overwrite EIP to point into the environment variables on the heap. If i've put my shellcode into say $HOME it'll execute it without a problem.
Also this does nothing to prevent heap overflows, which are often just as bad. If you'll remember the recent TSig bug in BIND 8 it exploited an off-by-one heap overflow which would in no way be stopped by this non-exec stack flag. The best prevention i've seen are using so-called "canary" values in between static buffers and saved return addresses, i.e. www.immunix.org