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:

[well_jung]

Really, if you are running rlogin or telnet, you have no reasonable expectationsof security. They all already known to be insecure.

Of course, it never hurts to reinforce this.

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

Re:More info:

[Anonymous Coward]

login is flawed, not telnetd or rlogin.. That means anything that calls login can be used to gain privileges. This includes SOME ssh implementations (those specifically choosing to call login rather than authenticate by themselves).

Re:More info:

[Oztun]

Yes and most major companies got infected with Code Red on their internal machines because they were to lazy to patch them.

I wonder how long it will be before there is a malicious Unix worm that teaches them the same lesson with telnet.

Re:More info:

[Syberghost]

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.

Either Ingevaldson needs to check his facts, or I'm going blind in my advanced age, because the patch ain't there.

That takes you to the fully supported patches.

Re:More info:

[pci]

If you work for a large company that likes using rlogin and telnetd, get them to switch to kerberos. It using the old commands (i.e. rcp, rsh, telnet, ftp, rlogin), but has updated them and includes single sign-on and encryption.
That way you don't have to teach all your developers and administrators to type "ssh" instead of "telnet" which has been working for them for years.

More information is at http://web.mit.edu/kerberos/www/

Re:More info:

[laserjet]

i wish i could... however i am sure you know how hard it would be to change a big huge company. nearly impossible. no, it would be impossible (at least from my shoes). the best i could hope for is to help the department i work for migrate to kerberos. It would take a policy change at the head IT level to make a real difference, I'm afraid, and that will not happen until there IS a major break-in or something. oh well!

Re:More info:

[benedict]

If they were working with Sun on a fix, why did Sun
take a week to get the patch out after the vulnerability
was disclosed?

I'm very unhappy with Sun's response time on this.

Let me guess...

[wiredog]

You can login as kt and get root.

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.

Re:This IS, but, but ...

[Rob Y.]

Even using SSH, users with valid accounts can use the login command to exploit this once they're SSH'd in.

SSH helps, but isn't a complete solution to command-line vulnerabilities.

Re:This IS, but, but ...

[wowbagger]

True, once somebody has a shell prompt, they can use any local exploit to become root. However, unless login is SUID root, this gives them no additional priviledges.

The FBI is disappointed. . .

[Slicebo]

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

Re:The FBI is disappointed. . .

[jd]

Shhhhhhhhhhh! The FBI still thinks that Windows is the only OS out there, and that Bill Gates invented the Internet!

Re:The FBI is disappointed. . .

[CoolVibe]

*SLAP* no, Al Gore invented the internet, not Bill Gates... sheesh...

:-)

Re:The FBI is disappointed. . .

[lildogie]

> Al gore invented the internet

That's why the fundamental unit of computer logic is called the 'algorithm'.

Re:See, Unix has problems too now.

[vinnythenose]

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.

Re:See, Unix has problems too now.

[Ivan Raikov]

Isn't this a logical fallacy? MS has vulnerabilities in its products, Unix System V has vulnerabilities, therefore Microsoft makes quality products.

I'd say there's a subtle, but important difference between insecure by design and insecure due to a programmer's mistake.

'Another Gaping security hole goes unpatched?'

[Anonymous Coward]

Isn't this where Michael says:
'Another gaping security hole goes unpatched by Microsoft... Uh, I mean, er, Sun' ?

Re:'Another Gaping security hole goes unpatched?'

[0xdeadbeef]

But a patch is already available, as is information about the vulnerability.

Re:'Another Gaping security hole goes unpatched?'

[Marcus Brody]

And they knew about this since October. Sheesh.... this is just typical non-disclosure tactics. I bet they just couldnt be bothered to fix it, so they didnt tell anyone. This is an impingement on my basic freedom and right to fix security loopholes on my own box.

Re:'Another Gaping security hole goes unpatched?'

[Ewan]

If you reads the vulnerability page at http://www.kb.cert.org/vuls/id/569272 you'll see it has taken 7 weeks from the first vendor response to the vulnerability, to the last one (the last being Sun, yesterday).

You will also see the comment: "An exploit exists and may be circulating.". This means that CERT and Sun have sat on this vulnerability for well over a month without telling anyone about the problem, despite an exploit being in use.

The story 2 days ago about Microsoft security was about a problem Microsoft had known about for 4 weeks (reported to them on Nov 19th).

Finally, the patch is available for IBM's AIX 4.3.3 and 5.2, but not as far as I can tell for Solaris 8.

However much you blindly hate Microsoft, they are not as bad as Sun in this particular situation.

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.

Re:Buffer overflows are inexcusable in 2001

[Greyfox]

I've been on about this for a while now. Basically the number of C programmers who think they can avoid buffer overflows greatly outnumbers the number of C programmers who actually can. it's just too easy to make a mistake in that language. C++ is a bit better but a lot of C++ programmers are just programming C with operator overloading and will continue to use the primative data types and they will continue to make the same mistakes.

While one might argue that an intrepreted language like Java could still have problems and might still be succeptable to buffer overflows due to buggy intrepreters, the fact of the matter is that it is much less likely that a server written in Java will ever lead to a root compromise. I counter that those arguments promote the fallacy that since perfect security is impossible, one should be willing to accept the current completely insecure status quo.

I find it odd that many people take it as a personal insult when you suggest that various servers be coded in a language that makes it much harder to make a fatal mistake. It's pretty obvious that C's a security exposure and it's pretty obvious that C programmers will continue to make the kind of fatal mistakes that cause root exploits. Must we continue to take chances with our systems out of a misplaced loyalty to an aging language?

Re:Buffer overflows are inexcusable in 2001

[benedict]

You're talking as if login was written last year. That's obviously not the case.

The RISKS of replacing existing code wholesale with new code that conforms to your idea of good practice are obvious.

Re:Buffer overflows are inexcusable in 2001

[ninewands]

I also know three ways to avoid buffer overflow, and they don't require any of the techniques you mention. Two are easy, one is tedious, but not difficult:

1) NEVER use

char *gets(char *s);

in a program. Use

char *fgets(char *s, int n, FILE *stream);

2) Use one of the kernel patches that renders the
stack non-executable. Then, even if the bad
guys manage to overflow a buffer, they can't
do anything with it.

3) Write your own low-level character-by-character
i/o handlers that stop accepting input before
the buffer overflows (that's the easy way), or
reallocates the buffer to be larger (that's the
more user-friendly way.

Numbers 1 and 2 aren't difficult at all, number 3 can be VERY tedious, but it isn't difficult.

Re:Buffer overflows are inexcusable in 2001

[awptic]

Although I agree with you in some respect, most buffer overflows ca easily be blamed just as much on laziness on the programmers behalf, strncpy, snprintf, strncat, etc. have all been a part of standard C libraries for some time now, gcc even warns against the use of some of the non-limiting variants of these. It doesn't even take that much effort to check over a program and ensure anywhere data can be read from an external source (i.e. stdin, command line, socket, etc.) that it's allocating enough buffer space to hold the maximum allowed input. Checking for format string exploits is also trival, greping through the source tree for "printf" and ensuring you use a format string rather than passing a buffer directly is trivial. That covers the simplest of exploits anyways, as for other ones such as the recent wu-ftpd bug... that was just bad coding, especially in such a widely used daemon, the code should have been completely rewritten long ago seeing as it has a long history of problems.

Re:Buffer overflows are inexcusable in 2001

[ChadN]

Number 3 is done; no need to implement it yourself.

See: http://www.linux.com/howto/Secure-Programs-HOWTO/l ibrary-c.html

Re:Buffer overflows are inexcusable in 2001

[CoolVibe]

number three is not really something I directly agree with. Why? Because you end up with n to the power of n implementations of [insert unsafe library call], which is BAD (tm). Another problem is buffers of which the size is not exactly known, these have to be malloc()'ed or allocated otherwise.

You are also forgetting that there are other ways to skin that cat. Rewriting functions, returning into libc or rewriting GOT entries are another way to wreak havoc.

There's only one thing that really works: Code Reviews. Heck, programmers are human, they can slip up and make mistakes, even if they are the most careful coders in the world (they are still human). More eyeballs catch more bugs. And the next random person can spot a problem in five minutes that you are trying for days to prevent.

Bugs happen. Deal with it. The advantage that we open source people have is that our code is open for peer review to a LOT of people, so these problems can be patched almost immediately.

I must be missing something

[overshoot]

This affects systems with telnet or rlogin accessible from the Internet? The implication is that these were somehow not vulnerable without this buffer overrun.
News to me.

Re:Let me guess... (moderators, read this)

[HMC CS Major]

The above comment is not offtopic. The above comment refers to trojanning c compilers to put a back door into login programs. This was not only written about by Ken Thompson (linked in the article above), but successfully accomplished by a bastard of a programmer.

Thus, the above comment is on topic, just over someone's head.

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:Another argument for open source

[reaper20]

Great point, please mod up!

This hole proves that open source works, and that closed source forces you to go through a slow vendor.

Too bad that people will say "*nix is just as insecure as Windows!".

Re:Another argument for open source

[tdrury]

You can post your patch here. That is why "Anonymous Coward" still exists.

-tim

Re:Another argument for open source

[duffbeer703]

If you are so smart, why are you running rlogin and telnet?

Re:Another argument for open source

[gilroy]

Blockquoth the poster:

It's an unchecked buffer, for God's sake. Most C coders can fix a problem like this in their sleep.

... which is good, since that's apparently where they're coding, too. :)

Re:Another argument for open source

[duffbeer703]

How would Sun open-sourcing Solaris change this??

The smartass troll who was bragging about his 3733t coding skills would be in the same mess.

Actually, he'd probaly be in a worse mess if he introduced a bug on all of his organizations Sun servers that Sun wouldn't support.

Re:Another argument for open source

[duffbeer703]

Anyone can access Solaris source code for $75

http://www.sun.com/software/solaris/source

/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:/bin/login - ssh

[tgd]

Most, but not all, SSH installations have it turned off.

man sshd

UseLogin defaults to "no" -- so unless you have

UseLogin yes

in sshd_config, then you don't have a problem.

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.

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

yay for CERT

[tribbel]

It does make me wonder why the people at CERT don't ever pretend to be skript kiddies. I just found this little tid-bit on a well known site which serves a lot of exploits.

Description: A "feature" of most telnetd programs is that they will pass environmental variables (like TERM, DISPLAY, etc) for you. Unfortunately this can be a problem if someone passes LD_PRELOAD and causes /bin/login to load trojan libraries!

Author: Well known, squidge (squidge@onyx.infonexus.com) wrote this, but I doubt you can reach him. Isn't he in jail now?

Compromise: root REMOTELY!

Vulnerable Systems: Older Linux boxes, I think SunOS systems, probably others.

Date: January 1996 maybe? Quite old but lives forever like phf.

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:IBM has an efix posted

[Florian Weimer]

If you wonder about AIX 4.2: It's vulnerable, too. but IBM probably won't bother to publish a fix.

Not mentioning unsupported, vulnerable versions in security advisories is probably not a good idea.

Re:IBM has an efix posted

[Chris Mattern]

I can imagine. Running AIX binaries compiled for
a version beyond what you're running almost
never works. Program hits a major library
incompatibility, falls down, goes boom. And, as
mentioned elsewhere, an IBM patch for 4.2 is
very unlikely; they stopped supporting 4.2 a
long time ago.

Chris Mattern

Oddly Tame vs. Zealously MS-Hating

[pOs*x]

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 :)

Re:Oddly Tame vs. Zealously MS-Hating

[4of12]

Yeah, a more condemming story title, as far as Sun is concerned, would be to accuse them of being as sloppy and arrogant as MS.

OTOH, if the markets and positions of Sun and MS were reversed I would expect Bill Gates and Scott McNealy to be able to instantaneously play the reverse roles without so ever as missing a single beat.

Re:Oddly Tame vs. Zealously MS-Hating

[Derkec]

While I think you're correct that Slashdot is generally more tolerant of Unix problems than MS problems, there is some legitimacy. We see critical security problems fairly rarely from the major Unix players and we see them more often from MS. Also, the Unix players tend to get patches out a bit more quickly. Sun and IBM have temp. patches out which probably means they have a bunch of guys using the patch and banging on it mercilessly to see if they can break it. When they determine it's not breaking, they'll call the temp patch the patch.

Entirely fair? No. Somewhat fair? Probably.

Re:Oddly Tame vs. Zealously MS-Hating

[Derkec]

I'm guessing you're reacting to "we see". By 'We' I meant the public at large. Other than that, I think it was pretty clear I was talking about my opinions.

When can we banish Telnet forever?

[reaper20]

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

Re:When can we banish Telnet forever?

[nutznboltz]

This is a /bin/login bug not a telnet bug.

Does not affect things like
telnet locis.loc.gov

Re:When can we banish Telnet forever?

[reaper20]

I know ... but still, removing telnet permanently can't hurt could it? Think of all the extra bonuses. It's an easy way of making all Unices more secure out of the box, and that can't be bad.

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

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.

Re:When can we banish Telnet forever?

[Xipy]

I would love to see a GPLed Java SSH terminal, but MindTerm is not one...

From the appgate.org page:

MindTerm is available free of charge for personal and non-commercial use. MindTerm may be licensed for commercial use for a fee

Re:When can we banish Telnet forever?

[sydb]

It's not GPL'd at all. It used to be. It's now 'free for non-commercial use'. See their licensing information.

However, have a look at my journal for some other similar packages, one of which is a fork of the original GPL'd Mindterm.

Re:When can we banish Telnet forever?

[hearingaid]

Some of us use telnet for other applications. Like, BBSes.

I run telnetd, but it doesn't give a shell. :)

Re:When can we banish Telnet forever?

[Richy_T]

And unfortunately, the old GPL version does not display properly in IE. Does your patch fix that?

Rich

Re:When can we banish Telnet forever?

[Tet]

Some of us use telnet for other applications. Like, BBSes. I run telnetd, but it doesn't give a shell. :)

Just like I use the telnet client, but never to log on to remote systems...

Re:When can we banish Telnet forever?

[sydb]

Not my patch...

The fork appears to be under active development, so probably :-) Best look for yourself.

Since michael won't do it

[edibleplastic]

here's your FUD for this one.

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

Re:Since michael won't do it

[juju2112]

At least Sun and IBM are admitting that the hole exists. Plus, IBM already has a fix out.

Re:Since michael won't do it

[talks_to_birds]

• "...keep in mind that anybody can take over your computer, steal sensitive files, destroy your machine, anything..."

You don't have a f*cking clue.

This is from CERT:

• "...Several implementations of login that are derived from System V allow a user to specify arguments such as environment variables to the process. An array of buffers is used to store these arguments. A flaw exists in the checking of the number of arguments accepted. This flaw permits the array of buffers to be overflowed."

That does not at all translate into "anybody can take over your computer, steal sensitive files, destroy your machine, anything"

Go back to Redmond, M$ whore.

t_t_b

Re:Since michael won't do it

[TheAwfulTruth]

Uh, yeah, weeks after they knew about it and only after it was publicly announced. That's pretty fscked. No two ways about it. Stop trying to white-wash this.

Re:Since michael won't do it

[Score Whore]

Actually buffer overflows like this are exactly how people "take over your computer, steal sensitive files, destroy your machine, anything". The ability for a remote fucktard to get remote access to your machine is always a bad thing, whether it's a remote root exploit or not.

Re:Since michael won't do it

[Derkec]

"This is a *serious* security hole, and it's all sun's fault"

Last I checked, AIX is only sold by IBM. So there is a problem in the code of both of the two major "big iron" players OS's.

Proof positive that everyone makes crap!

[Kaz Kylheku]

That's all, not proof positive that Microsoft (not MicroSoft, by the way) make quality products.

I wouldn't call this a level playing field either. Why not? Because of differences in the vendors' attitudes to the discovery of these problems.

Microsoft wants to sweep these problems under the rug; keep them as secret as possible and even criminalize those who discover them and make them known. They have a poor track record when it comes to timely releases for patches, and alerting their user base.

Do you, for instance, remember this slashdot story?

What about this?

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:Solaris Sparc kernel-level stack protection.

[btellier]

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

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.

Another article from InfoWorld

[Vodalian]

I submitted this URL from InfoWorld as well, but I guess the AC beat me too it. Look for it here.

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:Already patched on FreeBSD...

[CoolVibe]

That's not really the issue, it's about having the ability to send arbitrary information to a program (say, login, or every other prog that ends up being executed as root, be it suid or not). Still, being able to set env vars for the target program is _very_ dangerous ($LD_PRELOAD and $LD_LIBRARY_PATH come to mind)

A bug is a bug, and bugs need to be fixed. Period. You never now when this could end up in your face later. It's undesireable operation.

Best headline of the year...

[Have Blue]

...is found at The Register's coverage of this issue.

RISC CPU feature. (OT)

[CoolVibe]

This is actually a feature of the SPARC processor. Actually, all RISC processors can do it. It involves being able to mark pages like the stack as non-executable (for storage only). This means that such a thing could also be done on PPC based CPU's. Of the OS must support it :-)

Of course making the stack executable is not a miracle cure. You can still execute arbitrary code through another trampoline (like jumping into libc, rewriting/patching functions through trojaned libraries ($LD_LIBRARY_PATH and $LD_PRELOAD for example) or other tricks).

Sorry if this is a little offtopic, but stack smashes aren't the only way to skin a cat.

Re:RISC CPU feature. (OT)

[CoolVibe]

Another possibility/trampoline is the Global Offset Table (GOT), where the branch points to several library functions that the program uses are stored. This table is not read-only. Another possibility... And you don't even have to jump into libc (although you can) :-)

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.

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.

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

[FreeUser]

the idea that their[sic] above doing the same thing in this situation is nonsense.

Of course it is, and as many have said on other occasions Sun is a Micrisoft wannabe in many respects. No company is ever truly above anything, as its policies can change whenever management or corporate strategies change.

However, in the context of security, Sun (and IBM, who, lest we forget, was also an "evil empire" at one time) are generally both open and honest, and quite willing to be subjected to the open peer review process that is CERT and Bugtraq. Microsoft is not, and has used numerous unethical methods to silence technical review and criticism of the notoriously weak and vulnerable security of their operating systems, to the detriment of their customers, many industries (including the computer/software industry), and ultimately even themselves.

So, in the context of security Sun and IBM are, for the moment, not engaging in the unethical and harmful practice of silencing critics and whitewashing exploitable (and often laughable) security flaws in the way Microsoft is, nor are they likely to begin doing so anytime soon.

This does make them fundamentally different, and better, than Microsoft in the context of this discussion, and they will remain so until either Microsoft cleans up its act, or they themselves change in a negative manner down the road (possible but unlikely). In short, the criticisms (what Microsoft apologists call "bashing," despite their factual and verifiable basis) targeted at Microsoft WRT security don't even apply to Sun or IBM.

Indeed, the CERT advisory and resulting slashdot article are a very part of that open reporting process Micrisoft is trying to undermine and supressed. By reporting it, and owning up to it publicly, IBM and Sun are doing precisely the opposite of what Microsoft is doing, making the claim that they should be criticized in the same manner both ludicrious and indefensible.

Worse

[srichman]

Since Telnet and Rlogin are insecure by design, they should only be allowed to be used in environments where you implicitly trust all parties.

What "parties" are you talking about exactly? I assume you mean the network infrastructure between the client and the server? Telnet and rlogin are susceptible to network-level attacks: someone sniffs a password off the wire, or someone launches a man-in-the-middle attack to insert some commands into the telnet stream or something.

If I only telnet over networking infrastructure I trust (e.g., there are secured switches on both ends, I trust that my ISP hasn't been hacked, etc.), then I am safe. All users must authenticate with passwords to gain access. With these holes, anyone can remotely log in as root. Yeah, telnet/rlogin/rsh might not be as secure as ssh, but they're no where near the category of vulnerability that this hole exposes.

Re:See, Unix has problems too now.

[SuiteSisterMary]

Just to set the record straight -- UNIX was written by academics who felt they could trust everyone on their network and didn't have any need for namby-pamby coding practices like checking your return values and limited the size of inputs. It took years and years to fix this (and it ain't done yet).

Exactly. We'll see how secure NT is in twenty years, which is about how long UNIX has been having it's holes fixed. That reminds me, how did I EVER forget about sendmail? The vaunted MTA that you could exploit merely by typing 'debug' or 'wizard' at an SMTP prompt? Folks, let he who is without sin cast the first stone. That excludes ANYBODY using a UNIX or UNIX-like. If your OS even has a concept of ROOT, it ain't secure.

A different approach would help

[JMZero]

The focus on Free Software is fine. Bashing MS is fine. Plenty to bash.

But why not put it somewhere other than the front page article? Why not make the front page article concise, and let the rants come from others in the comments? Everyone can take their secret glee at the pains of MS, but when it's pointed out on the front page, it makes you sound insecure about your operating system's virtues. It's mudslinging.

After all, Linux isn't better because MS sucks, it's better because it's better.

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

That's not enough...

[flynn_nrg]

as it has already been cracked

Re:See, Unix has problems too now.

[SimHacker]

Absolutely. The people who think Unix has always been secure were born yesterday.

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

Untrue.

[mindstrm]

rlogin and telnet are 'insecure' in that data transmitted over them is insecure; this is known.. and ssh2 is a good alternative.

This buffer overflow bug is no different than those found in ssh previously...

so saying that 'You shouldn't be running telnet' is bullshit.
You shouldn't be USING telnet for anything you don't want sniffed is more accurate. Running it is only a problem in that it's yet one more available service.

Re:It's hard to exploit buffer overflows in Solari

[Syberghost]

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.

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

[CoolVibe]

No sir, I kid you not.

The libraries can be stored in /tmp, your ftp incoming dir, /var/tmp, or even (if the user has a shell account) in the user's homedir.

All that is needed is a "setenv LD_PRELOAD /dir/where/lib/is/foolib.so" or something similar and the damage is done. The library is dynamically linked into the root-owned program that's running with root privs and the system is "0wned", like they say (I like to say compromised, but that's just me).

The fix is of course to not let ssh set these kind of envvars, which is what they fixed in SSH, which prevented exploitation on *BSD which didn't have the buffer overflow.

Yes this was a bug in SSH, not in login :-)

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

[RFC959]

Yeah, but I don't think it's quite as easy as you make it out to be, either. From Solaris 8's ld.so.1 manpage:

SECURITY
To prevent malicious dependency substitution or symbol interposition, some restrictions may apply to the evalua- tion of the dependencies of secure processes. The runtime linker categorizes a process as secure if the user is not a super-user, and either the real user and effective user identifiers are not equal, or the real group and effective group identifiers are not equal. See getuid(2), geteuid(2), getgid(2), and getegid(2).

In short, you can't just make "printf" equal "exec /sbin/sh" and run your favorite setuid root program with LD_PRELOAD set.

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

[Richy_T]

So what are the risks for other su root programs? As a user, can I just set these env vars and run the programs and get root? Should su root programs be statically linked?

Hmm, actually, thinking about it, I'd probably better just research this.

Rich

Re:It's hard to exploit buffer overflows in Solari

[Florian Weimer]

Judging by the scarce description, this doesn't look like an ordinary buffer overflow (proper bounds checking on array of pointers is missing), so it's not clear if a non-executable stack will help here.

In addition, a non-executable stack doesn't prevent all exploits. In many cases, specially crafted exploits (using return-into-libc techniques etc.) are still possible.

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

[CoolVibe]

In the case of telnet, then yes, they are shielded off, but in the case of ssh, this wasn't true. Of course, you can leverage with geuid and geteuid, but if both are equal it still happens. /bin/login is being run as root here, because it needs to setuid() to the uid that you log in as. If the ssh daemon inadvertedly (sp?) still allows some of those dangerous envvars to be set, you are toast.

The suid bit matters, btw. If a non-root runs a suid program, then yes, some envvars are ignored/nullified. But if root runs it (of if it is being spawned by a root owned process), then that kite doesn not fly anymore and preloading just happens.

The daemon that runs as root must take care of these things, or just don't run that thing as root. It's btw perfectly possible to run sshd as a non-root, only then you can not bind the ssh port and I imagine you would have some problems running /bin/login (which is a bad idea anyway)

Re:See, Unix has problems too now.

[Florian Weimer]

Actually, the current problem is a UNIX hole (unless you are a BSD addict and do not consider System V to be a UNIX). All systems using a SysV-derived login share it.

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

Re:Are you kidding?

[Foogle]

How would you compile it? You don't have the original source to login.

Re:See, Unix has problems too now.

[SuiteSisterMary]

Well, I'm saying it's both. UNIX was specifically designed NOT to be secure, in a manner of speaking; it was a 'casterated' version of MULTICS, which WAS, as I recall, designed to be quite secure.