breeze-server.txt

`Date: Sun, 27 Dec 1998 00:32:34 -0500  
From: //Stany <[email protected]>  
To: [email protected]  
Subject: Breeze Network Server remote reboot and other bogosity.  
  
Good day. I am Ortodox Christian, so my Christmas is on Jan 7th, but in  
the spirit of giving, I would like to submit the following rant. It is  
rather lengthy, but IMHO is worth it. If Aleph1 feels that it is too  
lengthy, feel free to snip the parts that are boring ;-)  
  
A Breeze Network Server is a NetBSD 1.3.2 based system produced by  
WindDance Networks Corporation  
(http://www.winddancenet.com/products/breeze.html). It is marketed as an  
email, fax, printer, internet/intranet web server and a firewall.  
Physically it is an AMD K6/300 AFR system with 64 megs of RAM and 6 Gig  
IDE hard drive. It includes a LS120 disk drive as the primary floppy  
drive, and according to the documentation that drive is used for  
distributing updates to the system. The cost seems to be $3300 US.  
  
The system is marketed to be easy in use ("so even the secretary would not  
have any problems to set up Breeze in 15 minutes") and upon receiving it  
one has to connect up a keyboard and a monitor to it, power it on, answer  
a few configuration questions (What is my ip? What is my gateway? What  
is my subnet?) and then one should be able to access it with a web browser  
and be able to modify all sorts of things - add users, back up the system,  
set up filesharing etc. Following that, the keyboard and a screen are no  
longer needed.  
  
I have to admit that this was the first time I ever used NetBSD, but  
it is close enough to Solaris/SunOS that I manage ;-) However I might  
misinterpret important parts of NetBSD behavior, and if so, please  
correct me. After all, maybe this is the way the system is designed to  
behave, and not the bastardization of WindDance Networks (Ugh. I don't  
think so).  
  
After this system have appeared in our office (I worked for PSInet Canada  
and we were asked to evaluate if we would want to sell this to some of  
our customers), it have perked my curiosity, and one night I booted it  
into single user mode. It have provided me with a root shell, so I have  
remounted / read-write and looked around. gcc was installed. This seems  
to be a first mistake - one doesn't install a compiler on a production  
system, especially on a secure one, as it makes it so much easier to  
compile a sniffer and cause more harm. I have compiled ssh, installed it,  
and fixed my UID/GID to be zeros while I was at it ;-) (BTW I realize  
that it seem to be a simple one line change to disallow a system to  
provide an unpassworded root shell upon being booted into a single user  
mode).  
  
First thing I noticed once the system was running in multiuser mode was  
that apache was runing as root. IMHO this is another major problem, as  
apache should only need root to bind to socket. I decided to adjust the  
apache configuration files to use nobody as the default user, and once I  
have done that, I noticed that I could no longer even see the default  
starting page ("You have no permissions to access....").  
  
I have decided to take a cursory look at the cgi-bin scripts that the  
system was using. The scripts were not using any range checking nor  
sanity checks what so ever. A particular script have attracted my  
attention:  
root@wdbreeze:/usr/local/breeze/cgi-bin[24]# tail -3 configbreeze  
  
&rebootnow;  
exit 0;  
root@wdbreeze:/usr/local/breeze/cgi-bin[25]#  
  
Ugh. Is that not beautiful?  
  
That's right, *anyone* accessing  
http://BreezenetworkserverIP/start/configbreeze  
is greeted with "Internal Server Error" message, while the system reboots  
itself.  
  
It is interesting how the reboot is done as well: the script  
creates a file /tmp/reboot.now, and writes "Rest in Peace\n" into it. A  
daemon /usr/local/breeze/bin/rebootwrapper checks (a cursory strings on  
rebootwrapper shows that the daemon is also checking for /tmp/halt.now).  
if that file exists, the contents of the file are checked against an  
internal lookup table, and then the system reboots itself through calling  
/sbin/reboot  
  
I have done a few tests and another beautiful peecularity of the system  
came to light as well: if one creates an empty /tmp/reboot.now:  
root@wdbreeze:/[1]# cd /tmp  
root@wdbreeze:/tmp[2]# touch reboot.now  
the system doesn't reboot. No, it just locks up, and closes all network  
ports, which is deadly for a system that should be a primary network  
gateway/firewall for a small business. The behavior is very similar to  
halting the system, but the screen doesn't show the typical shutdown  
notices, and the last shows that the system was rebooted and not crashed.  
Oh, and the hard drive gets fscked on startup ;-)  
  
So if I am a malicious script kiddie, who have managed to obtain any sort  
of login on the system, all I have to do is set up a simple cron job to  
touch /tmp/reboot.now every five or so minutes, and I am laughing. It  
will take a good long while for someone to think about checking crontab on  
a system that all of a sudden started malfunctioning. With the amount of  
ports running on that system some exploit is bound to appear at some point  
that will allow me to get a remote login, or just add another line to  
root crontab.  
  
So here is the question for the list: What is the best way to make secure  
web interfaces to system functions like adding and deleting users or  
restarting systems? I realize that the best solution would be to ship  
the system with ssh and allow a quilified administrator to log into the  
system (As I believe Corel allowes on their NetWinder Webserver or  
NetWinder Group Server to log in into a shell and have control over the  
system. <http://www.corelcomputer.com/>) or ship the system with  
something like VNC <http://www.orl.co.uk/vnc/> that would allow an  
experienced user to connect to the X server and run software similar to  
RedHat Control Panel for system management, but once again there is an  
expense in training the user to be Unix "savvy". In fact the question  
might well be is there a way to minimize a learning curve for the  
users/administrators with Windoze/MacOS experience (It seems to be the  
environment that both Corel with their NetWinder product and WindDance  
Networks with their Breeze product are aiming at) for maintaining/managing  
the UNIX based system without compromizing security?  
  
//Stany, Sun Hardware Specialist, [email protected]  
  
P.S. I have telephoned Mike Pelley, Software Designer of WindDance  
Networks about 2 weeks ago about the problems with their product, and was  
promised a swift update, but so far have not been contacted and to the  
best of my knoweledge the software update was not shipped to us. I have  
cc:ed Mike to this message as well, and hope that someone at WindDance  
will get somehting done about the above.  
  
-------------------------------------------------------------------------  
  
Date: Thu, 31 Dec 1998 19:37:24 -0500  
From: der Mouse <[email protected]>  
To: [email protected]  
Subject: Re: Breeze Network Server remote reboot and other bogosity.  
  
> A Breeze Network Server is a NetBSD 1.3.2 based system produced by  
> WindDance Networks Corporation [...]  
  
> I have to admit that this was the first time I ever used NetBSD, but  
> it is close enough to Solaris/SunOS that I manage ;-) However I  
> might misinterpret important parts of NetBSD behavior, and if so,  
> please correct me. After all, maybe this is the way the system is  
> designed to behave, and not the bastardization of WindDance Networks  
> (Ugh. I don't think so).  
  
The problems you list really aren't NetBSD's fault, with the possible  
exception of shipping with a compiler installed, and that is more a  
mismatch between what the system is designed for and what it's being  
used for.  
  
Specifically,  
  
> gcc was installed. This seems to be a first mistake - one doesn't  
> install a compiler on a production system, especially on a secure  
> one, as it makes it so much easier to compile a sniffer and cause  
> more harm.  
  
Well, yeah, but it's not exactly difficult for a cracker wannabe to  
suck over a compiler binary - or compiled binaries, for that matter -  
>from elsewhere. Anyway, this *is* out-of-the-box for 1.3.2, though I'm  
inclined to agree with you that leaving it there is probably something  
WindDance shouldn't have done.  
  
WindDance was probably also in violation of the GPL, unless they  
shipped the necessary sources to rebuild gcc, or made the canonical  
offer of those sources.  
  
> (BTW I realize that it seem to be a simple one line change to  
> disallow [single-user -> free root shell].)  
  
Yes, you are correct.  
  
> First thing I noticed once the system was running in multiuser mode  
> was that apache was runing as root.  
  
1.3.3 does not come with apache out of the box. (There is probably a  
package for apache by now, but 1.3.2 didn't even come with the package  
tools, as I recall.)  
  
The rest of what you list is predicated on the web stuff - cgi-bin  
scripts and the like - and other WindDance stuff related to it, like  
the rebootwrapper. (A stock 1.3.2 system has nothing in /usr/local  
except a little directory structure, I think - though I never touch  
/usr/local so I don't readily recall what's there.)  
  
der Mouse  
  
[email protected]  
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B  
  
-------------------------------------------------------------------------  
  
Date: Thu, 31 Dec 1998 19:09:45 -0500  
From: Mike Pelley <[email protected]>  
To: [email protected]  
Subject: Re: Breeze Network Server remote reboot and other bogosity.  
  
Hello Bugtraq.  
  
I work for WindDance Networks Corporation. While developing our Breeze  
Network server mentioned in a previous message, we were interested in having  
some 'friendlies' try out the Breeze and offer suggestions regarding  
additional potential functionality requirements for their clients and  
others. As our current president, Rainer Paduch, was previously the  
president and vice-chairman of iStar before it was acquired by PSINet, he  
asked if they would take a look at our prototype. They accepted, so I made  
an image of one of our development machines for them to check out and  
recommend features/changes.  
  
A few weeks later Mr. Vardomskiy (Stany) called me and mentioned some  
security concerns, which he has outlined in his previous message. I  
explained that the version of the Breeze he received was not intended for  
customers, and most of the issues he mentioned were well known and the way  
they were because this was an image of my development machine and not a  
production machine. I explained that we had some things to work on, and  
that we had a security review planned after we had ensured that the machine  
was stable and functional.  
  
I am distressed that Mr. Vardomskiy has misrepresented the status of the  
machine he received and I do not understand why he was confused after our  
conversation on the phone. We have since created a beta release image of  
the Breeze. I did not promise to contact Mr. Vardomskiy, but I did mention  
that we would soon have a newer load available and would be happy to send it  
over if PSINet had time to evaluate it.  
  
If anyone has any specific questions about the Breeze or the issues  
mentioned before please contact me anytime.  
  
Mike Pelley  
System Designer  
WindDance Networks  
(613) 728-1700 x 15  
[email protected]  
  
`