Date: Sun, 27 Dec 1998 00:32:34 -0500
From: //Stany <stany@HTTP.NOTBSD.ORG>
To: BUGTRAQ@netspace.org
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, stany@notbsd.org

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 <mouse@RODENTS.MONTREAL.QC.CA>
To: BUGTRAQ@netspace.org
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

                               mouse@rodents.montreal.qc.ca
                     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 <mike@PELLEY.COM>
To: BUGTRAQ@netspace.org
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
mikep@winddance.net