Sun Microsystems Solaris hole opening way for hackers

Sun Microsystems Solaris hole opening way for hackers

Online vandals are using a two-month-old security hole in Sun Microsystems' Solaris operating system to break into servers on the Internet, a security expert said Tuesday.

Researchers witnessed the attack when one intruder broke into a Solaris server under intense observation as part of the Honeynet Project, an initiative to develop ways to turn spare computers into digital fly traps to study and document actual Internet attacks.

"One of our honey pots got whacked with it," said Lance Spitzner, project manager for the Honeynet Project. "As far as we know, it was the first time we saw (this flaw) used in the wild."

The flaw, commonly referred to as a "buffer overflow," allows a specially crafted packet of Internet data to cause a computer to give an online vandal full access to its capabilities. In this particular instance, a component of Solaris used to remotely run applications contained a buffer overflow, and an attacker found the weakness, Spitzner said.

"The bad guy accessed our system, downloaded a back door, and made it so he could log in anytime he wanted," he said. "Then, he logged in a couple days later and loaded a denial-of-service tool to attack several online chat servers."

Denial-of-service, or DoS, attacks attempt to overload or crash a computer, thus making it inaccessible.

The Computer Emergency Response Team, or CERT, Coordination Center, an online security watchdog, first reported the vulnerability last November.

On Monday, the group posted an advisory about the use of the flaw, adding that administrators should install the patch from Sun, limit access to the vulnerable service, or disable the service.

Solaris is Sun's proprietary variant of the Unix operating system. Last October, the FBI published a list of flaws that affected major operating systems, including Solaris.

The UNIX community started CERT because there were so many holes in Unix/Linux that they needed a clearinghouse. One of the most notorious bugs or should I say series of bugs allowing hackers to take superuser control of the unix box occured in the sendmail program. Sendmail runs as root on unix boxes. When you connect to a unix box port 25 the unix box runs sendmail and it gets your keystrokes. If you knew how you could send sets of data to sendmail that would crash it. When sendmail crashed it left you logged in as root, which, sendmail runs as. So there you are logged in as root to a unix box because of a bug in sendmail.

you hear a lot of these 'stack' bugs on unix machines but it's only windows that really has security problems.

The problem is based on error handling routines called exceptions.

In the early days of programming a programmer had to handle every error. As we went to Object oriented programming and the concepts of code and data abstraction that approach would no longer work. So the concept of exceptions was invented. When an error occurs the program creates an exception which calls an exception handler funciton. It goes back up the method and function chain until it reaces the main entry point of the program. Somewhere in this chain the exception is supposed to be trapped and handled. But since this is an abstraction programmers often do not know about all possible exceptions so the fail to handle a lot of them. One advantage of exceptions is that an unhandled exception does not crash the program. Unhandled conventional errors usually do. If a hacker can manage to generate an execption that is not handled the hacker ends up back at the main entry point to the program.

The other things that programmers do is put the security in last. As the program is run and tested programmers don't want to keep setting permissions. So they set permissions as zero qantities. Thus if a permission value is set to 0 you have permission and if it is set to 1 permission is denied. By that I mean permissions are turned off.. They are not turned on. So if permissions are not turned off, the user has them.

Since an unhandled exception when the program starts puts the cracker at the entry point, if the permissions have not been turned off yet, he is at the entry point with all permissions available to him. Becuase operating systems set uninitialized objects to zero and zero means you have permission.

I recoded our companies products so a permission has to be set to 1 to enable that permission. A cracker may still find a way into my application, but when he gets in, he has no permissions. All permissions are set to zero and that means in my case he has no permissions not all. He can't do input, he can't get output. Once he is in, the computer appears totally locked up to the cracker. He just goes away.

With my system even if the cracker can get into the bank, he still finds the vault is locked he can't do anything at all. With the Sun, Linux and Windows sytems, if a cracker gets into the back, he finds the vault unlocked and he has total permission to do everything.

That makes the computer safe. I have never been able to proove that a cracker could not find a way to generate an exception. But I can prove that if he does it on my systems he can't get permision to do anything harmful.

All three operating systems need to invert permissions so if the permissions are all zero there are no permissions granted to do anything at all. And if you have zero permissions you can't set anything to give you permissions.

First, I agree with you (to some degree) on this point: If you set permissions low by default, there's literally nothing that an attack can accomplish other than, perhaps, crash the process (which will then restart presumably without harm). The problem is that many of these communication daemons have to run with root access in order to open the low-numbered ports (ie. ftp); hence, when a buffer overflow attack occurs, it's pretty bad.

Second, if you think you're safe from attack, I've got news for you. Many attacks come from people with inside knowledge on how your security works. If it's possible for your app to raise its privileges then someone else will eventually find a way to do so. It's just a matter of time. The only way to truly secure a server is to unplug it from the network.

Because some of the people hacking are smarter than some of the people programming. This will always be the case.

Bull Sh*t.

There are two axioms that every professional programmer knows. For every offense there is a defense that will prevent it. Defences are always invented after offenses are created.

To program a totally secure program the programmer has to invent all possible attacks and then invent defenses that will prevent all possible attacks.

An attacker has to find one attack that has not been defended against.

The attackers job is several orders of magnitude easier than the programmers.

The problem with UNIX is raw sockets in UNIX require root privileges.

If all I give a program of root's privileges is Raw Socket privileges it is damned hard for the cracker to do much. Stuff can be done but it is a lot easier if you have all of roots permissions.

What you do is patch the kernal so there is a new privilege type that is user plus raw socket privileges. That lets SMTP servers run with just uers privileges ( it is the SMTP relay component's DNS resolver that needs the raw Sockets). You don't need raw sockets for FTP.

Making a program have root privileges in order to do raw sockets is the same thing Bill Gates can be accused off doing ... that is sort of.

However NT contained an undocumented feature that allowed an ordinary user to run a dll that could create raw sockets. Did you ever wonder how you can run ping on an NT/2000 server with just user privileges? PING needs raw sockets. I figured if PING could do it I could too. And I did.

I reverse engineered the Dll that PING called to create the raw socket so a program that knew how could create raw sockets could do so with ordinary user privilges.

I wrote the SMTP, POP3 and IMAP4 components that are included with Delphi. I also wrote the DNS Resolver component. My code created Raw sockets with out administrator (root) privilges on Windows NT, 2000 and XP Server and Advanced server.

Microsoft later changed their documentation after people started asking how I did it. In my reverse engineering I discovered that Microsoft had taken the BSD UNIX socket code and only modified it so it would compile with the MS C++ compiler. That was a real discovery. It meant I could use UNIX source to understand windows code.

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.