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

I thought only Micro$oft had vulnerabilities...

[B00mZilla]

how can this be?

Re:I thought only Micro$oft had vulnerabilities...

[jmcnamera]

Yeah, besides recent Linux FTP and Unix BIND and sendmail problems, among others, why nothing besides MS has problems.

More seriously, we all need to grow up and past our anti-MS obsessions.

Re:I thought only Micro$oft had vulnerabilities...

[Anonymous Coward]

Dumb fuck

As if a vulnerability in a service a well-admistered web site won't allow you to get to unless you have physical access to the box is the same as the Petri dishes known as Microsoft products.

How many years until your Microsoft Certified Software Installer certification you paid thousands of dollars to get is useless and you won't be able to play on toy computers any more?

Re:I thought only Micro$oft had vulnerabilities...

[Anonymous Coward]

Yeah, you showed him. For all you know he's a linux admin cracking a joke.

You dumb fuck.

Re:I thought only Micro$oft had vulnerabilities...

[B00mZilla]

oh no, I've been mightily insulted by an anonymous coward who makes such broad assumptions that only show his ignorance and not mine.

Whatever shall I do?

Oh, and modded as a troll by the penguinistas eventhough I run linux myself?

wherever shall I go?

You /.'rs take yourselves WAY too seriously.

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:

[HMC CS Major]

This actually is not a new vulnerability. From FreeBSD Security Advisory: FreeBSD-SA-01:63.openssh:

Topic: OpenSSH UseLogin directive permits privilege escalation

Category: core/ports
Module: openssh
Announced: 2001-12-02
Credits: Markus Friedl
Affects: FreeBSD 4.3-RELEASE, 4.4-RELEASE
FreeBSD 4.4-STABLE prior to the correction date
Ports collection prior to the correction date
Corrected: 2001-12-03 00:53:28 UTC (RELENG_4)
2001-12-03 00:54:18 UTC (RELENG_4_4)
2001-12-03 00:54:54 UTC (RELENG_4_3)
2001-12-02 06:52:40 UTC (openssh port)
FreeBSD only: NO

I. Background

OpenSSH is an implementation of the SSH1 and SSH2 secure shell
protocols for providing encrypted and authenticated network access,
which is available free for unrestricted use. Versions of OpenSSH are
included in the FreeBSD ports collection and the FreeBSD base system.

II. Problem Description

OpenSSH includes a feature by which a user can arrange for
environmental variables to be set depending upon the key used for
authentication. These environmental variables are specified in the
`authorized_keys' (SSHv1) or `authorized_keys2' (SSHv2) files in the
user's home directory on the server. This is normally safe, as this
environment is passed only to the user's shell, which is invoked with
user privileges.

However, when the OpenSSH server `sshd' is configured to use
the system's login program (via the directive `UseLogin yes' in
sshd_config), this environment is passed to login, which is invoked
with superuser privileges. Because certain environmental variables
such as LD_LIBRARY_PATH and LD_PRELOAD can be set using the previously
described feature, the user may arrange for login to execute arbitrary
code with superuser privileges.

All versions of FreeBSD 4.x prior to the correction date including
FreeBSD 4.3 and 4.4 are potentially vulnerable to this problem.
However, the OpenSSH server is configured to not use the system login
program (`UseLogin no') by default, and is therefore not vulnerable
unless the system administrator has changed this setting.

In addition, there are two versions of OpenSSH included in the
ports collection. One is ports/security/openssh, which is the
BSD-specific version of OpenSSH. Versions of this port prior to
openssh-3.0.2 exhibit the problem described above. The other is
ports/security/openssh-portable, which is not vulnerable, even if the
server is set to `UseLogin yes'.

III. Impact

Hostile but otherwise legitimate users that can successfully
authenticate using public key authentication may cause /usr/bin/login
to run arbitrary code as the superuser.

If you have not enabled the 'UseLogin' directive in the sshd
configuration file, you are not vulnerable to this problem.

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:

[rodbegbie]

They knew about it for months, but haven't fixed it? It affects versions of the operating system going back years? It allows malicious hackers to take complete control over a user's machine?

Bloody Microsoft. Oh, wait... that was two days ago. Hmmm... wonder why this story doesn't have the headline "Another Gaping Sun Security Hole Goes Unpatched".

rOD.

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:

[HMC CS Major]

Your sarcasm only shows how little you pay attention to unix security. The flaw in "login" has been around for a while, and has shown up on various security mailing lists. For instance, here is one from FreeBSD. From FreeBSD Security Advisory: FreeBSD-SA-01:63.openssh:

Topic: OpenSSH UseLogin directive permits privilege escalation

Category: core/ports
Module: openssh
Announced: 2001-12-02
Credits: Markus Friedl
Affects: FreeBSD 4.3-RELEASE, 4.4-RELEASE
FreeBSD 4.4-STABLE prior to the correction date
Ports collection prior to the correction date
Corrected: 2001-12-03 00:53:28 UTC (RELENG_4)
2001-12-03 00:54:18 UTC (RELENG_4_4)
2001-12-03 00:54:54 UTC (RELENG_4_3)
2001-12-02 06:52:40 UTC (openssh port)
FreeBSD only: NO

I. Background

OpenSSH is an implementation of the SSH1 and SSH2 secure shell
protocols for providing encrypted and authenticated network access,
which is available free for unrestricted use. Versions of OpenSSH are
included in the FreeBSD ports collection and the FreeBSD base system.

II. Problem Description

OpenSSH includes a feature by which a user can arrange for
environmental variables to be set depending upon the key used for
authentication. These environmental variables are specified in the
`authorized_keys' (SSHv1) or `authorized_keys2' (SSHv2) files in the
user's home directory on the server. This is normally safe, as this
environment is passed only to the user's shell, which is invoked with
user privileges.

However, when the OpenSSH server `sshd' is configured to use
the system's login program (via the directive `UseLogin yes' in
sshd_config), this environment is passed to login, which is invoked
with superuser privileges. Because certain environmental variables
such as LD_LIBRARY_PATH and LD_PRELOAD can be set using the previously
described feature, the user may arrange for login to execute arbitrary
code with superuser privileges.

All versions of FreeBSD 4.x prior to the correction date including
FreeBSD 4.3 and 4.4 are potentially vulnerable to this problem.
However, the OpenSSH server is configured to not use the system login
program (`UseLogin no') by default, and is therefore not vulnerable
unless the system administrator has changed this setting.

In addition, there are two versions of OpenSSH included in the
ports collection. One is ports/security/openssh, which is the
BSD-specific version of OpenSSH. Versions of this port prior to
openssh-3.0.2 exhibit the problem described above. The other is
ports/security/openssh-portable, which is not vulnerable, even if the
server is set to `UseLogin yes'.

III. Impact

Hostile but otherwise legitimate users that can successfully
authenticate using public key authentication may cause /usr/bin/login
to run arbitrary code as the superuser.

If you have not enabled the 'UseLogin' directive in the sshd
configuration file, you are not vulnerable to this problem.

Now, what does this mean to you? It means that there's a flaw in login, and any user can gain escalated privileges if they can find a way to call it from a privileged program (if it was suid root, it'd be almost trivial to gain root privs without using telnetd or sshd). The email I pulled the info from was send on december 4th. It was corrected by FreeBSD december 3rd. Obviously in the last week, thousands of solaris boxes have been sitting open to vulnerabilities because they were not notified. And yet, you act as if everyone was told the second it was discovered.

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:

[Anonymous Coward]

Doesn't it also mean pretty much anything compiled to use login is 'vulnerable', IOW anything someone cobbles up to use to penetrate the system?

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:

[Anonymous Coward]

This actually is not a new vulnerability. From FreeBSD Security Advisory: FreeBSD-SA-01:63.openssh:

Announced: 2001-12-02

Hmmm... 1 day old. What exactly do you consider to be new?

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.

Re:This IS, but, but ...

[lunky]

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

SSH isn't even a partial solution to local vulnerabilities. Ssh is used as a security precaution which will prevent the bad guys from sniffing out sensitive information.

The use of ssh in this case is prudent b/c it does not (by default) use the login mechanism.

This article describes a REMOTE expolit which represents threat that has nothing to do with the LOCAL expoit that is available to users with valid accounts on a machine.

Re:See, Unix has problems too now.

[utdpenguin]

ooops. i lost my sarcasm
and /sarcasm tags. :-(

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

[malxau]

No, they're probably relying on it for mass distribution to AIX and Solaris users (like this)...since it's not open source, they could put some pretty cool stuff into a /bin/login, and what better place to put it...

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.

This might be very bad.

[Krapangor]

People confuse often all different types of unix operating systems with linux or *BSD.
If there is now this huge hole in Solaris/AIX many people will think there is a security hole in Linux or even OpenBSD.
Especially mainframe firms confuse these operating system, even IBM ported accidentially Linux to their big severs, because they though it's some kind of new unix brand.
So this security hole might help microsoft very much to install their operating systems everywhere because they say: Hey look at this hole at linux !!! which is a lie but people won't know the difference, really.

So this might be very bad.
I wonder if some script kiddies are behind this hole, this is always the same: You look, and, hey, there is a script kiddie behind the security hole ! (The famous script kiddie surprise.)

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

[doooras]

pardon me, but it seems like security holes are found in microsoft products on a regular basis. unix holes are found VERY rarely. how can you say it is a level playing field?

Hackers do not target MS products because of "percieved" vulerabilities... they target MS because their products are KNOWN and EXPECTED to have holes.

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.

Re:See, Unix has problems too now.

[Medievalist]

This is proof positive that MicroSoft make quality products.

Naah, it's proof positive you're a blockhead. Microsoft isn't even in the article. And Sun has security just as lame as M$oft, as any bugtraq subscriber is well aware.

The main difference between Sun's approach to security and M$oft's is that Sun will publish a patch for a vulnerability even if there is no published exploit. MSoft must have their hand forced as evidenced by L0phtCrack and friends.

Why am I answering a troll anyway? OK, I'll go soak my head now.
--Charlie

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

[Anonymous Coward]

Oh... ok... well let me just get out my VB compiler and rewrite login in VBscript... I'm sure then it will be sekure..... sure... Isn't IIS written in VB, and we all know how secure that is.

Re:Buffer overflows are inexcusable in 2001

[Anonymous Coward]

Isn't IIS written in VB
no

Re:Buffer overflows are inexcusable in 2001

[jaavaaguru]

It is not OK to trust legacy C programs to be secure: they are full of security holes until proven otherwise.

Internet Explorer is a particularly good example of this point.

Re:Buffer overflows are inexcusable in 2001

[Anonymous Coward]

I would trust "legacy" code a little more.

It's BUG FIXED. People are aware of it's previous problems and make sure it doesn't happen again. To throw away code like this is wasteful. People should realize that rewriting is not always the answer. If your rewrote login you might introduce new bugs until "proven" otherwise.

Re:Buffer overflows are inexcusable in 2001

[Ace Rimmer]

Ad 1. This is not a solution. You would have to formally prove that even the interpreter/compiler has no flaws.

Ad 2. This is perfect but show me a usable (non 101-function) program with a formal proof of its functionality.

Ad 3. Same as ad 1.

More, I think that both rules you suggest are already used - s/legacy C programs/programs/g

Re:Buffer overflows are inexcusable in 2001

[entrox]

But - Prove that the compiler/interpreter has no such flaws and by induction all programs written with it are free from such flaws.

Re:Buffer overflows are inexcusable in 2001

[Anonymous Coward]

It's a lot less secure than Fetchdoggiemail which ESR maintains.

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

[Anonymous Coward]

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

Buffer overflows are just one type of security problem. There are many others that are equally bad or worse.

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

via a buffer overflow perhaps.

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

No. complex code is what causes security problems. When code is complex, no one understands it, and spots problems like buffer overflows. Rewriting something in a different language won't prevent this.

The fix for security problems is to isolate privileged code into VERY SMALL PIECES, which can be human-reviewed and easily understood.

Then, execute the remaining 99% of code in a safer security context.

/bin/login shouldn't exist. There should be one program that is a front end to login, running without privileges, and another piece that does the real work.

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

[Score Whore]

Actually you can still use buffer overflows when the stack is noexec. So there.

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.

Re:Buffer overflows are inexcusable in 2001

[Anonymous Coward]

you, sir, are a fucking moron. iis is not written in vb. that is the dumbest thing i have EVER heard

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:I must be missing something

[jhernand]

The design flaws you're talking about require some social engineering (someone must previously use it to login) and other conditions to be met (intruder can sniff the particular packets containing the password) in order to stage an attack. What makes it different is that nobody made a programming mistake - it does exactly what it's advertised to do.

In this case, the system is vulnerable as soon as you put it on a network due to a code quality control problem.

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.

Re:See, Unix has problems too now.

[Cave Dweller]

Yep. From the bugtraq advisory by ISS:
"Secure Shell (SSH) implements encrypted terminal connections, and it is designed to replace insecure protocols like Telnet and Rlogin. Recent versions of SSH implement their own version of the login program, and are not vulnerable. "

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

[Anonymous Coward]

And that is why I believe that open source has a future and Sun does not.

There is a lot more to sun then just solaris you know. Sun is not even against open source- they are heavy into open office and gnome. I believe they wanted to make Solaris a little more open (and they have since then just not as open as people want) but patents and stuff got in the way. Besides, Sun would be able to make it a hardware company anyway.

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

[ethereal]

Of course, now that he's posted non-anonymously, any bits of Solaris code that show up here will be assumed to be from him, so he still can't post them without fear of detection.

Re:Another argument for open source

[Anonymous Coward]

good troll.
appeals to all the slashdot sensibilities. well done.

Re:Another argument for open source

[Anonymous Coward]

Sun has been telling us for over a year now......don't use telnet ... don't use telnet ... don't use telnet .... don't use telnet....

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

[Anonymous Coward]

WTF?!? Are you saying that open source is better because *you think* that it is faster at getting bugs fixed? At first I thought that you were going to say something stupid like "open source is better because it doesn't have bugs blah blah blah", but I guess you checked your brain at the door on that one. Good thing too.

Listen: Bugs will exist in ANY code. Agreed?

1) The only way to eliminate bugs prior to release to public is to have a really good quality assurance implementation (note that I did not say 'plan').

2) The only way to get fixed code to the people is to have a really good software release process.

This covers early identification and "fix to public" rates, most attributed with customer dissatisfaction. Do you agree? Open source, from all I can tell, only covers one; frequent releases. I do see a quality product in the open source products, but I don't see the independent integration testing and requirements certification to prevent bugs? I bet Sun does independent testing and requirements cert. I bet Sun does security testing and performance testing. Does that mean that they don't have bugs?!? No. There will always be bugs.

Who tests YOUR code?!? YOU?!?!?

Re:Another argument for open source

[F2F]

sometimes it is impossible to switch abruptly to a new technology (in this case ssh). mostly due to inertia and inability (or lack of resources) to educate all users on the matter.

at our university (3000+ employees, 15000+ students) some of the servers still have telnet open -- it's much more cost effective to _not_ have to teach all of them how to use putty...

can you imagine how expensive would be to switch the entire administration from openvms to unix? the bigger the body the more inertia it has.. and sometimes a sysadmin's desire to use new technology is simply not enough to move it...

--
flame on

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

[Anonymous Coward]

How many Solaris sysadmins do you know? The poster's point was that most of them aren't 31337 enough to have a signed NDA with Sun, so they're forced to wait for Sun to release a binary patch. And with Sun taking months to do "regression testing" (cf "scratching their asses"), that leaves a lot of Solaris systems vulnerable for a really long time.

Re:Another argument for open source

[Anonymous Coward]

closed source forces you to go through a slow vendor

That is a very hasty generalization, and most large companies release patches very early. Anybody who follows the sort of things will know this.

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

That is very hypocritical; you made a generalization like that from (basically) the opposite side, then hate people who do the same from another point of view.

On a slightly offtopic note, Microsoft has checked Windows XP very carefully for buffer overflows. There should be significantly less buffer overflow vulnerabilities in Windows XP, but we have yet to see.

Re:Another argument for open source

[F2F]

i've heard of regression testing before -- sun has to do this for all their patches.. sometimes it takes up to a week...

or they can simply release something that's broken and then patch the patch (linux-type release schedule :)

Re:Another argument for open source

[Kiwi]

Listen: Bugs will exist in ANY code. Agreed?

In general I agree that bugs are a fact of life, like death and taxes. However, there are coding styles that can minimize the number of buffer overflows in code:

• One can create a special string library which is resistant to buffer overflows (strings being structures which a "maximum length" value). For example, my DNS server uses such code to minimize buffer overflows (the string library is documented in man pages).
• One can write code in a style where the possibility of the code being placed in an "unknown state" is minimized.
• One can avoid strings wherever possible

Now, the reson I feel that Solaris had these kind of buffer overflow is because Solaris just has too much #%$ old, crufty code. The original /bin/login was developed at a time when people just wanted the code to work, and in a day an age where today's exploits did not exist.

It is possible, with today's knowledge of security issues, to code in a style which makes these kinds of security holes very unlikely. Look at Dan Bernstien's code. Look at Chris Ferret's VsFtpd.

This is why I feel that Solaris is slowly dying: Becuase Solaris has, for whatever reason, lost the motivation to replace their codebase with the features that a modern Linux system has. Some Solaris administrators are so afraid of change that they don't want to replace the Solaris userspace with the vastly superior Linux userspace. Like Eric Raymond said to the idiots that think making Python a requirment to build the kernel is a bad thing, progress happens.

- Sam

Re:Another argument for open source

[Anonymous Coward]

Jesus. You think Linux is better than Solaris.

You think ESR has something relevant to say.

You think Python is worth paying attention to.

You must have no friends at all!

Tell me, what's it like, talking to a mirror to have a conversation?

I bet your dick is tiny.

Re:Another argument for open source

[guacamole]

Months ago, I faxed Sun a really long contract that gave me the right to download their source distribution.

And if you have read and signed that license agreement you should know that you are NOT
allowed to use, NOT EVEN IN-HOUSE, any software derived from this free Solaris source distribution.

So, by using the patched version of login you are viollating the agreement that you have signed and faxed to Sun.

Re:Another argument for open source

[duffbeer703]

Anyone can access Solaris source code for $75

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

Re:Another argument for open source

[Mike Hall]

I have the foundation source license as well. login.c is not in it. I don't know what you were patching. If I am wrong and it is located in the source tree someplace, please let me know.

I looked in osnet_volume/usr/src/cmd/login and it is not there. Did you find it in another dir?

Re:Another argument for open source

[Kiwi]

To whoever wrote that: For your personal health, I strongly reccomend that you visit a psycologist

It is obvious that you have some serious emotional problems that posting to slashdot will not solve.

Seriously: See a doctor or other mental health professional. The sooner, the better.

I hope that you get better soon. It is obvious that you are very miserable.

- Sam

/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

[ethereal]

Interestingly enough, I first heard of this attack on the dshield mailing list last night. So your sig is particularly apropos.

...although it really should go in the sig space, not in the body of the comment, because some of us have sigs disabled.

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

[cachedout]

I believe this would also require sshd to be running setuid root which is not the default behavior.

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.

Re:See, Unix has problems too now.

[Quasar1999]

This is mud int he eye of everyone who claims that *nix is inherently more secure than Windows... This is proof positive that MicroSoft make quality products.

Good point! However, This is not 'proof positive' that Microsoft makes good products... Where on earth do you draw that conclusion from?

And although you are correct in that *nix and Windows both have their fair share of security holes and other vulnerablities, the key thing to remember is volume. There are a lot more computers running Microsoft's OS than any other. Thus a single security hole in Windows affects Millions of computers (if not billions), while a bug of this sort on a Unix platform only affects Thousands...

And add to that the fact that in companies *nix environments are usually run by (on average) more experienced 'hackers'/sysadmins than in companies where the environment is mostly 'Microsoft' based. ( Please don't flame me on this, just look up the stats on google) Most *nix admins make their network as secure as possible during and after installation (since it's not a point and click procedure), while most NT admins are surprised to learn that their system is wide open to attack after installation...

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

Re:See, Unix has problems too now.

[KingAdrock]

Hackers do not target MS products because of "percieved" vulerabilities... they target MS because their products are KNOWN and EXPECTED to have holes.No, hackers target MS products, because they are more widely used, and generally used by people whose biggest concern isn't security. It's like going into a neighborhood where nobody locks their doors. Not that their doors can't be locked, but they feel like they have no reason to do so!

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.

Re:yay for CERT

[uucp]

No. That is a reference to a bug in telnetd, not login.

This problem (so I'm told, if anyone has any better info feel free to correct me) has to do with adding name=value pairs after the username when you login (which was a SysV only feature IIRC).

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

[hoggoth]

How many times will we find new buffer overflow security holes before developers STOP WRITING STUPID CODE?!

Use strncpy instead of strcpy.
Problem solved.

Idiots.

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

[envelope]

Well, the problem is with the C runtime library, isn't it? Let's lobby ISO to amend the standard to exclude strcpy and all other unsafe functions.

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

[Anonymous Coward]

strncpy is worse
1) It pads the buffer - ie. it overwrites more memory than strcpy if the destination size is different than expected
2) It's fucked with mbcs

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

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

[hoggoth]

You are kidding, right?

If you have the abillity to put your own replacement libraries on the system, I think you can stop trying to hack into it with buffer overflows. You already 0wn the system.

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

[Score Whore]

It's not a matter of putting replacement libraries on the system. It's a matter of being able to put libraries on the system. They don't have to replace shit. That's what LD_PRELOAD does for you. If, for example, you have a company where developers have access to a server but not access to root on that server... well they do actually have root, if they want it.

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: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: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:I AM **SICK** OF STUPID BUFFER OVERFLOW HOLES!!

[Sandmann]

Here is an excerpt from the man page for ld.so:

The necessary shared libraries needed by the program are searched for in the following order

• ...
• Using the environment variable LD_LIBRARY_PATH. Except if the executable is a setuid/setgid binary, in which case it is ignored.
• ...

and later:

• LD_PRELOAD: A whitespace-separated list of additional, user-specified, ELF shared libraries to be loaded before all others. This can be used to selectively override functions in other shared libraries. For setuid/setgid ELF binaries, only libraries in the standard search directories that are also setuid will be loaded.

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

[xsbellx]

Tried the 4.3 version on a 4.2 box....It was pretty ugly. I would NOT recomend. :(

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

Re:IBM has an efix posted

[xsbellx]

Sorry, it was more of an FYI. I realize that IBM has withdrawn support for 4.2 but there are enough people that are running older versions (even as back as 3.2.5) for one reason or another that I thought it might have been semi imformative.

"Buffer the overflow slayer"

[nadie]

theregister also mentions this, along with the idea that using SSH instead of Telnet is the quick solution.

Re:"Buffer the overflow slayer"

[O2n]

... but using blindly ssh is prone to the exploit itself (see the "UseLogin yes|no" discussion)

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

[Anonymous Coward]

michael is a retard in case you didn't notice. he is the worst of a shitty lot of editors on slashdot. if va software needs to free up some money they should fire that asshole.

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

[bigjocker]

Well, I'm glad you care to stand up and ask. There _is_ a problem, but in this case Sun has already announced that they care about it, posted a temporary patch and scheduled a tested patch for next week, not to mention that the people with the Solaris Source CD has the _chance_ to fix it themselves.

The only stand M$ has had for the IE vulnerability is deny it. I believe that justifies the 8 paragraphs we read yesterday.

Re:Oddly Tame vs. Zealously MS-Hating

[cgleba]

Others agree:

http://www.bbspot.com/News/2001/12/passport.html

Re:Oddly Tame vs. Zealously MS-Hating

[Anonymous Coward]

You're missing the fact that slashdot is a zealous mouthpeice for niche views.. If you don't trump up a story about MS everyone will see it as what it really is.. just another bug in computer software.. Of course that means you have to downplay other serious bugs..

In fact, this post is going to be never seen by 99.9% of the people on this site for the same reasons.

Welcome to 1984. Slashdot has had their Double-Speak ispell module working overtime for years.. Ever wonder why the spelling is so bad? Exactly.

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

[Anonymous Coward]

And since when, sir, did you express the opinion of all slashdot users?

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?

[Anonymous Coward]

Yes, let's get rid of telnet on internal networks.

That doesn't solve the problem of POP3, IMAP, SMB, HTTP, 5250 emulation and the gazillion other insecure protocols that we use.

I'm not saying that ssh is bad, just that you Use-SSH-not-telnet robots are really boring. How about providing some real PKI like kerberos so that using secured protocols is less of a pain in the ass?

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?

[heh2k]

believe it or not, telnet is useful for a lot more than just remote logins (which it is least useful for).

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?

[ethereal]

You could remove in.telnetd, but keep telnet the client for testing mail servers, etc.

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?

[Anonymous Coward]

Is there a binary for my NetWinder? How about the HP-UX machine I log on from at home?

No, I don't have an ANSI C compiler on the HP-UX box.

You were saying about 'nobody can have any excuses'.

Java? Hahahahahahaha! You're rich!

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?

[sydb]

Xipy, have a look at these.

Re:When can we banish Telnet forever?

[Anonymous Coward]

Removing ethernet support would make all Unices more secure out of the box, and that can't be all bad.

Re:When can we banish Telnet forever?

[Pinball Wizard]

Do you know of an ibm3151 terminal emulator that works with ssh? Preferably something thats not $100+ per seat? The only ones I've ever seen work with telnet. So unfortunately, telnet will have to stay. At least its behind my firewall.

Re:When can we banish Telnet forever?

[smkndrkn]

Yeah stop selling me cigarettes and beer too cause its bad for me. I think one of the great things about Linux/UNIX is the fact that you have options. Whether or not you choose good ones is what makes you a good or bad administrator. If some people are not smart enough to use ssh instead of telnet thats their choice. It may not be a smart one but at least they have the option. How abou we disable telnet by default..that would be a great start...

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?

[Anonymous Coward]

Ever do a search for 'ssh' on docs.sun.com?

Re:When can we banish Telnet forever?

[yomegaman]

You could tunnel it through ssh. Just do a 'ssh -L2023:remotehost.somewhere.com:23 remotehost.somewhere.com' first, then tell your terminal emulator to connect to port 2023 on localhost, and it should just work. You can even add a '-C' flag to the ssh command to have it compress the traffic, which can be helpful over slow links.

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.

Re:When can we banish Telnet forever?

[Anonymous Coward]

Any clueful admin disables R** series with SSH functions, and hand assembles a modified FTP - the next biggest hole, followed by banning mail attachments other than text. Those that dont, deserve the foreseeable.

All these active HTML extensions, plugins -- you have been warned. I am puzzled though - I thought most 2.4 based distros all now use ssh by default - telnet is getting hard to come by.

Well obviously...

[billmaly]

They should be taken to court, made fun of, boycotted! A security hole, my god, well I run Solaris, thank goodness I'm not affecte.....What's that?? It affects what? Oh....oh my....OH WAITER!!!! A plate of crow please! :)

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

[Hobart]

Well said!!

Thank you!

Re:Since michael won't do it

[Anonymous Coward]

One has to wonder why and how someone can be so infatuated with Microsoft.

And what does Slashdot.org have that a Microsoft drone is interested in (except trolling)?

Your operating system is inferior, you know it, the world knows it, and you only defend it because any OS with an "X" or "x" on the end scares you.

The fat, goatee, Birkenstock, tech-support Winblows user has had his day. Go home dot-com worshipper.

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

[Anonymous Coward]

Actually it does, how does it not? Buffer overflows mean at minimum you can take over the complete permissions of the process with the overflow bug. And with deamons that's frequently root. (Even though it SHOULDN'T be) Sounds like you "Don't have a f*cking clue" Go back to nap time and leave the playgound to the adults.

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

[mooneyguy]

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

How is it Sun's fault? I thought it was a fault in the System V code. Since when did Sun write System V? And has Sun been sneaking its code base in to AIX? Those guys are really devious, eh? ...

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.

s/Solaris or AIX/any networked computer system/

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.

Re:Since michael won't do it

[Anonymous Coward]

Congratulations for exposing yourself as a total moron. Drop me an IM when you figure out what a buffer overflow is, kiddo.

Re:Since michael won't do it

[deaddrunk]

I get a bit tired of hearing people moan about the anti-Microsoft bias of this site. Why don't you go somewhere else more to your liking then? After all, most of the media websites have a decidedly pro-MS bias (see the "aren't they wonderful for providing a version of Windows that doesn't crash so much" reviews of XP for example).

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

[lars_stefan_axelsson]

Yes, the article with the "canaries" is StackGuard.

And besides, you often don't need any shell code as such, there is enough cruft in different libraries that you can call to do your dirty work for you. See for example the last (windows) link of of sans buffer overrun page. Which is a good page to get you started on buffer overruns.

Re:See, Unix has problems too now.

[Anonymous Coward]

Yup, apparently most slashdot readers didn't become sentient until 1998 and were unaware of UNIX's absolutely fucking terrible security record. They comfort themselves with the idea that Unix has ugo permissions and the Win98 that was on their mom's presario does not.

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

Heck, it was only a couple years ago when there would be a RedHat Advisory Of The Week, and Windows got relatively little love from the whitehats. The only thing you can really say about MS is that they should have been paying attention to the pain on the Unix side and been somewhat proactive.

Re:See, Unix has problems too now.

[ryusen]

boy... i'm sure glad you added this follow up post.. for a second i almost thought i was reading zdnet forums

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.

Now I can use the AIX box I bought at auction!

[Spoing]

If this fails, anyone know if PPC Aix disks can be mounted on an x86 Linux box? Proper partition and fs support enabled, of course.

Background: The box came from a defunct internet delivery service. I wonder what corporate records I'll find? Definately customer records if the admins didn't wipe the database. It's a good thing I'm ethical. I wonder how many customer records from defunct Internet-focused IPOs are now in the hands of crooks?

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

[sammy.lost-angel.com]

I didn't think FreeBSD used System V login.

I'll take three examples from the CERT Advisory:

Apple Computer, Inc.

Mac OS X and Mac OS X Server are not vulnerable.

Caldera

We are not using a SystemV based /bin/login, we are using the BSD
originated rlogin tools. All OpenLinux products are 'Not Vulnerable'.
NetBSD

NetBSD does not use a System V derived login, and therefore, NetBSD is
not vulnerable.

Ok, none of these are FreeBSD, but you can clearly see the BSD originated rlogin tools is not vulnerable.

Please correct me if I am wrong, or provide me with a link with more information about FreeBSD and this latest security problem.

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.

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

[Zillatron]

In fact, on Solaris, any attempt to execute the stack is logged.

Well sir, the good news is that if we get your car back in one piece the thieves might leave fingerprints behind.

Re:page widening post!

[Anonymous Coward]

Alternatively, when will the Slashcode guys do the intelligent thing and place each comment in a seperate table so that morons can't fuck up the page for everyone else? Curently, the attempted 'fixes' are laughably ineffective and serve only to break comments (particularly with URLs) posted by regular slashdotters.

Re:See, Unix has problems too now.

[ClosedSource]

Hackers target MS products for political reasons. They want MS to look bad and Unix to look good.

Best headline of the year...

[Have Blue]

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

Re:See, Unix has problems too now.

[Anonymous Coward]

Level playing field? Let's see .....

Bug count:
Windows = 65,000+
*nix = ...1?

Yeah, looks really level to me.......

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)

[Anonymous Coward]

Solar Designer wrote a patch out for linux on x86 to implement this.

The problem is the same as the problem with noexec stack on Solaris: It doesn't work. Putting the expoit code on the stack is just convienent, if it stops working because people use these patches/options, you can just simply return into libc with data on the stack.

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

Re:RISC CPU feature. (OT)

[thogard]

The exploit takes advantage of the windowing operations aren't done in user space, they are done in system space which isn't disabled by the noexec_user_stack = 1. What is needed is a never_ever_ever_exec_the_stack = 1 option because the kernel and its modules aren't using an executable stack (I hope).

Has anyone noticed how long it takes to get bug fixes out of sun these days? Their usb keyboard drivers have been broken for over a year (can't cope with two keyboards correctly) and now the most trusted of trustworty programs is broken and no fix.

Re:page widening post!

[Deagol]

Hmmm... seems browser dependent.

Works for IE 6.0, Navigator 4.78, & Mozilla 0.9.2.1, but not for Konqueror 2.2.2.

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.

Stop the "you had it coming" litany!

[juliao]

Everytime a story comes around about a security hole i hear the "you had it coming, you shouldn't have run it anyway". And it's starting to get on my nerves.

So people shouldn't run telnetd, because it's unsafe, now should they? So "it's ok to have a bug there, don't blame Unix"? Well they shouldn't run IIS either, because it's unsafe, so it must be ok to have a bug in IIS too...

Stop the double standards. We'll never be taken seriously as a community of free-thinking, mature, Unix/open_source/whatever believers until we start acting like mature people in the first place.

It's a bug, and it's bad. It's been posted in October and Sun is taking ages to fix it, and so is IBM. That is _real_ bad. So face it.

Yes, this is different from the Microsoft/IIS/Outlook exploits. But you have to KNOW the difference before you can TELL the difference. And the difference is THIS IS A BUG, MICROSOFT PROBLEMS ARE USUALLY FLAWS.

THAT is the main difference, THAT is what sets Unix apart from Windows. Both have problems occasionally. One because it couldn't help it, the other because it didn't care. Now that's a world of a difference.

Re:Stop the "you had it coming" litany!

[Anonymous Coward]

"the other because it didn't care"

you have proof? How do you know some of the IIS security holes were not just unfound bugs like this one?

Re:Stop the "you had it coming" litany!

[pclminion]

Stop the double standards. We'll never be taken seriously as a community of free-thinking, mature, Unix/open_source/whatever believers until we start acting like mature people in the first place.

Not all of us hold double standards. I would guess that most of the people here on /. that have these double standards are of the high-school type. Who cares what these people think? Lots of Unix people are level-headed, just like you.

There already is a community of mature, free-thinking believers in open source. This community includes you and me, along with thousands of others. Take pride in this community, and don't worry so much about all the idiots :-)

Re:Stop the "you had it coming" litany!

[fredrik70]

"Yes, this is different from the Microsoft/IIS/Outlook exploits. But you have to KNOW the difference before you can TELL the difference. And the difference is THIS IS A BUG, MICROSOFT PROBLEMS ARE USUALLY FLAWS.
"
How do you mean? From what I've seen there's no really design flaw in IIS that causes it to have all these exploits, more like sloppy coding, or rather coding withouh security in mind.
But you think different?

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

[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:Sun et al aren't demanding silence, M$ is

[Yankovic]

Uh, you're dead wrong. Sun has the most restrictive NDAs when it comes to talking about hardware or software bugs. The ECC RAM issue is the most recent one which actually got out into the press.

In fact there was another bug that was absolu...

%2&;(

NO CARRIER

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

[Anonymous Coward]

Yup... Sun's very much at fault for that one. It's also fun to note that the faulty part came from none other than IBM... when IBM knew about the fault already and didn't inform Sun. So now we have two companies to blame over that one. :)

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.

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

[Anonymous Coward]

What a bunch of shit. Of course Sun are demanding silence from security professionals who discover bugs, security holes, and exploits.

In short, Sun & Co. have done a lot that is improper or worthy of customer or professional outrage.

Biased as they are, Slashdot and its readership are more than a little wrong in bashing Microsoft's security policies, and in not reporting security lapses of other firms as well, even though these other firms have behaved in a much less ethical and open manner.

In short, Mr. Nealy Flunky, get over yourself. If slashdot's pro-Crap Software and (though this is a sub-clause of the previous) pro-GNU/Linux bias upsets you so much, then go hang out in a pro-Sun forum where you can suck up as much marketing drivel as your heart desires, while leaving the rest of us in peace.

Partial retraction...

[Otter]

Errrr, reading more about this, I see that depending on what ssh implemenattion you're using and how it's configured, you probably aren't vulnerable to this. (Not that there's anything magic about the login control in ssh packages, but it's not the stock login that's the problem here.)

Nonetheless, most of the people ranting against telnet are talking about its vulnerabilty to sniffing, which is an important weakness but has nothing to do with this.

Of course....

[Anonymous Coward]

since this is a non-Microsoft hole, nobody goes around bashing and thrashing Sun. I'm obvisouly not a *nix advocate, but I'm not a Microsoft agent either. FUCK THAT PAPER CLIP. Anyway, score -1 for the flamers and +1 for the bias!
One day the trolls will rise and conquer, and the mighty will fall and their bodies turn to dust. THE END

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

[Anonymous Coward]

On handle of the door they couldn't unlock?

You left out the option to make the stack non-executable.

Are you kidding?

[b.foster]

Online anonymity is a tool to facilitate open discussions. It is not here to help people break copyright laws with impunity. Don't you realize that the more privileges we abuse, the fewer privileges we will have? Or are you one of the people who constantly reposts "OT III" here just because you can get away with it?

Breaking the law anonymously is not an act of civil disobedience; it is an act of cowardice, and it will bring little sympathy from the public or from the people who are in positions of power.

Bill

Re:Are you kidding?

[tdrury]

No, I'm not kidding. I would have no problem posting a one-line patch to a buffer overflow check. I would have to see the patch and the NDA, but I don't see how it would violate the spirit of the agreement. But I would probably post anonymously anyway to avoid any issues. No, it's not my place to interpret the agreement/law, but this is too serious a problem with a simple solution.

I don't trade in warez. I don't download music I don't already have. I disagree with most of the zealots on /. who feel "information should be free". I'm trying to exercise common sense.

-tim

Re:Are you kidding?

[Demonspawn]

The problem is, under Solaris, having him post his one line patch is useless. He would have to patch the entire source to /bin/login so that you have more than one line of code to compile. While I can see Sun not minding one line of code (corrected code, not even thiers) being posted, they would not allow the entire source of /bin/login to be posted.

--Demonspawn
Kant speel, don't kare.

Re:Are you kidding?

[Anonymous Coward]

He could post a diff.

Re:Are you kidding?

[Foogle]

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

Re:Are you kidding?

[Electrum]

No, but people who have the Solaris source do. Of course, they would have to sign the NDA, but it is probably worth it to those running Solaris.

Re:page widening post!

[Deagol]

Damn... he got me in the "MS Watches..." article with the same trick.

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

[Dimwit]

Whoops! Forgot to say that those commands go into /etc/system. Sorry for replying to my own post. :)

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

[Peter La Casse]

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?

Plus all users on all clients that use any part of the network infrastructure.

Obviously, this is only possible in isolated and well-controlled networks, but it is possible. Example: a Beowulf cluster that's not connected to an outside network.

Re:Worse

[srichman]

What "parties" are you talking about exactly? I assume you mean the network infrastructure between the client and the server?

Plus all users on all clients that use any part of the network infrastructure.

??? Not "any part;" only the path between the client and the server. For instance, right now my computer is plugged into an ethernet jack in the wall. On the other side of this jack is a wire that travels through the walls to a locked room that contains a switch. Lots of other people are plugged into this same switch, i.e., there are lots of other "clients using part of the network infrastructure," but because they aren't on the path between me and the server I'm telnetting to, they can't sniff my traffic or (reasonably) launch a man-in-the-middle attack. If we were all connected by a hub, it would be a different story, but then I'd consider the people I share the hub with to be on my path to the server.

Re:Worse

[Peter La Casse]

Initially I noted what you point out, but I removed it from my post because I have no guarantees that a user that's connected to some other part of the network I use can't remotely connect to the part of the network that I'm using. Hopefully that makes sense.

For example, somebody could send malformed packets that exploit telnetd (which was the original point of this conversation) from their host, through the ethernet switch and to the server in question.

If I'm lucky enough to (correctly!) trust everybody who is physically connected to my ethernet network, then I can run telnetd, etc. without worries. In practice, people aren't this conservative; they usually "trust" a firewall to filter out everybody they don't trust. It's also possible to have machine that's connected to an outside network, but the outgoing connection does not have any protocols or programs running on it that are able to be exploited.

Unix has always had problems: X11 for example.

[SimHacker]

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

Some times, "design" is 100% equivalent to "a programmer's mistake".

That is obviously the case with X-Windows, the world's first fully modular software disaster. It was a mistake to even design it. A mistake carried out to perfection. The defecto standard. Flaky and built to stay that way. Complex nonsolutions to simple nonproblems. Form follows malfunction. Ignorance is our most important resource. It could be worse, but it'll take time. More than enough rope. Power tools for power fools. Putting new limits on productivity. The cutting edge of obsolescence. The art of incompetence. The defacto substandard. You'll envy the dead. Even your dog won't like it.

-Don

Odd place for M$ advocacy

[LeninZhiv]

Windows and most other operating systems don't have a problem with this.

Hmm, so your argument is that companies should be installing Windows on their AIX servers?

Good luck with that.

Re:Odd place for M$ advocacy

[Anonymous Coward]

His argument is that Slashdot (or, more accurately, michael) should try to curtail the tendency towards drooling idiocy and attempt some semblance of even-handedness in their reporting.

No-one expects perfection: this is Slashdot, home of the gibbering masses, and the editor in question is michael, known for his outbursts and ill-considered actions - but some effort towards not being totally two-faced and hypocritical can only be a good thing.

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.

Trust nothing

[Evil MarNuke]

In terms of network design, you should not trust anything. The whole idea of trusting a computer is obsolete. It dates back to a world where everyone knew everyone else.

Today network are designed and built with idea and mind set that anything on the network could be cracked. Machine you know are cool need to prove who they are. Don't assume anything. By default insecure service should be disabled and never used. The insecure terms should not be used. When the phase `telnet into a box` is heard it should should be corrected with `ssh into a box`. Anyone that still uses r services or telnet for access get what is coming to them.

Death to port 23!!

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:See, Unix has problems too now.

[MisterBlister]

Bug count: Windows = 65,000+ *nix = ...1?

Heh why don't you just come out and say 'Gee, I just started getting into this *NIX thing last week, when my friend said it was cool?'. Anyone that has been around for a long time realizes that UNIX has been a source of major security flaws for decades. Consider that the much-ballyhooed "Internet Worm", which took out pretty much the ENTIRE INTERNET in its time relied primarily on some really stupid bugs in UNIX-based programs such as sendmail. Before 1992 or so, a determined script kiddie could root virtually any Internet accessible UNIX box within hours using only widely known buffer overflow and/or library path problems.

I don't mean this as an anti-UNIX rant. My point is simply that complex software is bound to have bugs until companies start development policies which highlight 'security first' in the way that "Extreme Programming" highlights 'test first'. The economics of doing this, though, are such that no company that wants to make money is very likely to bother in the near future. Thus we'll have this never-ending cycle of finding and fixing bugs. And this goes for all commercial platforms, UNIX and Windows alike.

Anyone that gets on a high-horse about such things, either pro-Microsoft or pro-UNIX, just shows he/she doesn't have all the facts, or is the equivalent of a religious fanatic who only sees what he/she wants to see.

PS. I realize there are projects to address the issue I spoke about, namely OpenBSD. And that's great. I disagree on many of the merits people claim that OSS has (most of these merits are theoretical only and never pan out in practice), but OpenBSD, by mixing security minded developers and the removal of profit as the primariy motive for working, has been doing quite a lot to make *BSD based UNIX systems more secure.

If the mainstream press reported it ...

[nickmdf]

If the mainstream press reported it, the headline would be something like:

"Killer Login Virus Affecting Everyone's Computer"

and totally skip over the specifics until the last sentence in the jump section on page 14b.

If anything, as much as the maintream media jumps on M$ for its business practices, it too is caught in the "Microsoft is Computing" attitude in that any M$ product vulnerability must be industry-wide.

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.

Re:blah

[Anonymous Coward]

I thought the vulnerability they were talking about was in the login process and not telnetd. This seems to refer to an older exploit.

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

Lets Blame it on MS!!

[Anonymous Coward]

Lets Blame it on MS!

After all, every single news post seems to have some dispariging remark about MS! And we all know MS is the only company that makes software with bugs!

Re:More info: (Kerberos)

[Isao]

One may run the kerberized versions of these programs to achieve secure access.

It is not clear from the releases if the kerberized versions are also vulnerable.

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

[Anonymous Coward]

hey moderator freak.....

just caus someone pointed out your problem don't go bashing on them... you like 2 or something

due to the last sentance posting as AC for fear of retribution

Another buffer overflow???

[Anonymous Coward]

Why are these things still popping up, including in new code (not meaning to imply the code in this reported case was new), after all these years??? Does anyone out there have a fucking clue about how to program any more???

I wish every programmer guilty of creating this kind of error would be forced to spend 6 months doing nothing but maintenance coding on undocumented, hacker-level C. Maybe that would instill at least a glimmer of respect for quality in them.

Re:Another buffer overflow???

[V.P.]

Because after all these years people still think that programming in a language without array bounds checking is so damn expensive.

...have already won

[Anonymous Coward]

If we can't use Telnet, then the terrorists have already won!

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:It's hard to exploit buffer overflows in Solari

[Anonymous Coward]

There are patches available for linux to do this too, but they never went in for one simple reason: noexec-stack doesn't work. Search for "return into libc."

It does at least stop the kiddies though, since all the distributed exploits execute code on the stack. But any skilled programmer could transform a code-on-stack exploit to a return-into-libc one, so all you get is a false sense of security.

Re:See, Unix has problems too now.

[ClosedSource]

So saying "Hackers do not target MS products because of "percieved" vulerabilities... they target MS because their products are KNOWN and EXPECTED to have holes. " is not flamebait, but saying that "Hackers target MS products for political reasons" is.

I think this flamebait rating is based on political considerations as well.

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

Benign Buffer overflow ?

[Kevin O' Riordan]

From the CERT advisory linked above:

HP-UX is NOT Exploitable. It is NOT a security issue with HP-UX. HP-UX does have a benign buffer overflow which is the only reason HP-UX is listed as "effected" above. In any case, the buffer overflow has been fixed by HP.

What the hell is a "benign buffer overflow" ? Either the stack can be smashed or not - the benevolence of the attacker is left as an exercise to the reader ...

Re:Benign Buffer overflow ?

[uucp]

Two possibilities;

1) Not all buffer overflows deal with stack variables. Overruns in the data area might cause a crash, but there is less of a chance of security problems with them. Granted, there are still some fairly classic security issues that were caused by data-area overruns, but there's less of an issue with it overall.

2) The stack on the HP-PA RISC grows in the direction opposite of most other processors (it grows up not down). This occasionally impedes the production of ereet sploit code.

So, I'm leaning toward #2 as to why this isn't immediately exploitable on HPUX, and is therefore called "benign." It's just a guess, though.

yes

[Anonymous Coward]

It's a NON SEQUITUR.

Re:page widening post!

[Anonymous Coward]

Because if they made separate tables Netscape 4 would take forever to scroll with... since we all know how masterful that rendering engine is with the table tag.

Silence? They sure as Hell are.

[Anonymous Coward]

In short, Mr. FreeUser Flunky, how quickly you forget the incident where RedHat is berated by other Linux and Unix companies for informing the world of a rootable security exploit effecting wu-ftp prior to the other companies completing their fixes. All of these companies want the security notices to be held back until it's fixable. But if you're sick of concern by companies for the welfare of their clients and consumers, they perhaps you should hang yourself on slashdot where the idiocy roams free ... oh, wait.

Re:See, Unix has problems too now.

[Anonymous Coward]

Is that the same reason that hackers have found a million holes in UNIX software?

Because they want to make UNIX look bad and OpenVMS look good? (it ain't the MS guys finding those holes...)

Re:page widening post!

[Anonymous Coward]

There are some days I'm glad I read /. in lynx.
Lynx Version 2.8.2rel.1 (01 Jun 1999)
Built on openbsd2.7 May 5 2000 21:26:30

Not affected.

Re:See, Unix has problems too now.

[Anonymous Coward]

Jesus, you're an idiot. Will you kindly take twenty seconds of your time to learn about UNIX holes - all caused by galloping featuritis?

I'd say that you're about 15 years old. You're certainly not much older than 25 - all 25 year olds who've spent time in the industry laugh their asses off about UNIX and its "accidental root exploits".

UNIX's track record is a joke. In fact, its current record is a joke, too - but you seem to be way down the road of Windows bashing, so it'll be difficult to convince you. What's your IP? Post it here, and suffer the (trivial UNIX security hole) consequences.

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

[haggar]

but this needs a followup instead since Dimwit left something out. Namely that those set commands belong in /etc/system
Not really, I don't think there is any Sun admin that wouldn't have at least guessed that those were kernel parameters that needed to be set in /etc/system. After all, the original poster even mentioned rebooting the computer in order to activate them.

So, your remark is informative for non-Sun administrators.

*sigh*

[Anonymous Coward]

Please, learn C++ and use stringstream. Buffer overflow bugs don't need to exist.

Problem with Sun's Patch Distribution process

[Anonymous Coward]

apparently this was patched back in October, but didn't make it out of testing yet (oops) - so there's probably a T-Patch available, and I'm guessing a public one should show up on Sunsolve in a day or 2. I would venture to guess patch 111085-02.

Security through obscurity implemented by others?

[Anonymous Coward]

Researchers announced the vulnerability before fixes were available because they had uncovered evidence in Internet chat rooms that hackers had already started developing tools to take advantage of the hole, according to Dan Ingevaldson, a team leader at ISS' X-Force research and development lab.

- CNet

So, this vulnerability was discovered in October, but was going to be left secret until the patches were completed? Sounds painfully similar to the requests made by another company that demands that the nature and demonstration not be made public until a fix is prepared.

Hypocrisy, or selective ignorance?

Sun cooperates, MS bribes.

[jotaeleemeese]

MS is demanding that information like this is not made available to the general public.

Sun and IBM go and patch their systems as fast as they can.

You tell me who deserves bashing.

Re:page widening post!

[sebol]

Mozilla 0.9.6 is affected ..

Re:See, Unix has problems too now.

[deaddrunk]

So what you're saying is that Unix is more mature than NT, rather than ageing technology, as is usually stated by pro-MS people. I suppose I'd better use that, instead of waiting 20 years for MS to learn how to produce reasonably secure software.

What's that sound?

[Anonymous Coward]

shhh. I think I can hear it clearly now.

[Waaaaahahhhhh]

Ah yes, the distinctive sound of a Microsoft shrill whining about the Slashdot "bias." Jeeze, that's like complaining about the "pro-gun" bias at a local NRA meeting.

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.

Re:See, Unix has problems too now.

[ClosedSource]

Well, if hackers have found a million holes in Unix, it must be less secure than Windows. :)

Assuming that Unix isn't too screwed up today, I imagine that many of these holes were found at a time when MS was not on hackers' radar screen. They just wanted to hack and they were familiar with Unix. Later anti-MS became a crusade and they had another reason to hack. I can't prove this theory but I base it largely on the percentage of anti-MS posts I see on slashdot. It doesn't mean that the slashdot users are hackers, but I think it is a fair indication of the thoughts of Unix users.

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

[polymath69]

...informative for non-Sun administrators.

That's basically a fair criticism. But I'd like to point out that since Solaris works so well out of the box, a not small number of Solaris admins I know have never had to change a kernel parameter. Unlike SunOS, and indeed Linux, where kernel rebuilds are practically de rigeur, Solaris generally just works, without tweaking. No doubt this has a lot to do with the fairly homogenous hardware (speaking only of Sparc here, not x86 Solaris.)

It's too bad a crack has been found for even this protection, but it was probably inevitable. Crackers tend to start with a lot of ingenuity; mix in a deep knowledge of the machine and they will find the weak spots, eventually.

Troll

[Anonymous Coward]

Mod parent down

(MARKETING???)

What a lame troll!