On Tue, 30 May 2000, gramble none wrote:
> Hey Paul when you do an install, do you use the GUI tool to administer the
> firewall? My guess is yes since that is where most people do it now. Did
Nope, I've not used the remote GUI tool to administer Gauntlet, I don't
like the extension of trust to a remote client. If you are too lazy to
get off your butt and go to the firewall to admin it you pretty much
deserve what you get IMO. Bad guess.
> you happen to know there is a neat little bug in the GUI tool? Oh yea, if
Yes, I'm aware of it, for the installations were remote management was
necessary, we always restricted it to a specific host, preferably enhanced
with filters on the inside screening router. Once again a zero sum game
if you're following a reasonably paranoid scheme. Your exploit only works
if you can hit the management port, not something I'd be incline to let
the bulk of my luser community do, let alone the world-at-large.
I've seen three other people/organizations install Gauntlet, and they
followed almost all of the same procedures (with the exceptiion of
enabling remote access to 2 internal addresses versus walking to the
server.), so it's not far off my experience base that such procedures are
normal for Gauntlet installs if you're picky about who installs it.
> you turn off the Cyberpatrol proxy, it says its off, but nope, its still
> running. So now lets assume that there are installers out there that think
> they are turning it off even when they are not. Not such a neat little
> issue eh?
Anyone can be incompetent when verifying that they've turned something
off, netstat, lsof and ps aren't that difficult to use though are they?
Oh, maybe they're worried about how long it takes to install the product
instead of how well it's installed?
> >>Perhaps also because most of them have had the product for more than 30
> >days? It certainly took a lot longer than that at my last install to get
> >through testing/patching/testing
>
> It takes you longer then 30 days to install a Gauntlet Firewall? Please
> remind me note to invite you to do an install at our site! I agree that
> there is testing and patching, but 30 days?
It took over 60 days to get patches for all the bugs that we cared about.
It's rather *obvious* we weren't invited to your installs since it was
over _6_ months after the formal release and we found show stopping bugs
which killed proxies, authentication and services.
Sure, you can install anything in an afternoon, but you can't *verify* it
in a large-scale production environment without significant testing, I
find it difficult to test a month's worth of processes and procedures
without using a month to do it in unless I'm cutting corners, and frankly
I prefer to let something sit for 45 days in configured but testing mode
prior to putting it in place, and then another 45 days before relying on
it. Since I was salaried, the time to install wasn't as critical as
installing correctly, especially since my butt was on the line if it
wasn't installed correctly, didn't handle load, didn't have known scale
points, didn't have complete and correct failover, etc.
Now perhaps your quick installations are sufficient for your level of
paranoia, in which case I'm _sure_ that such bugs are _extremely_
unsettling for you, but that's not the way I approached major product
changes in critical infrastructure at my own site for any product,
switch, router, firewall, authentication server or whatever (with an
exception for Cat5- we generally installed/tested that same-day ;) )
At one point we had about 17 open issues with NAI tech. support. Some of
them were site or configuration specific, but NAI fixing 2 a day would
have taken us over the month quite easily- and they supposedly had to QA
each patch before we got them.
Perhaps your measure of software quality, functionality or your testing
methods are less exact or less stringent. Perhaps you don't use the HTTP
proxy or the authentication services, or the FTP proxy, so you never ran
into any of the bugs we encountered in our testing.
> >As to why there's been little discussion, perhaps it's because it's not
> >that interesting. Since you can MD5 the installation through normal
> >procedures and archive those off-box, it's not that difficult to check to
> >see if your system has been changed if you had Cyberpatrol activated.
>
> The concern is not if the system has been changed. Obviously now people are
> becoming aware of the issue. The problem is the people who were not aware
> or might still not be. If I were going to exploit this, I would just write
> code that gave me a remote shell when I attacked the port. I would then
> just restart the daemon when I was done. Now there is no code loaded on the
Both of those are loggable events. If you don't leave a way back in, then
your intrusion won't give you much after-the-fact access and you can do
much more damage with DNS, SMTP or HTTP access to a trojaned client.
Getting a remote shell is non-trivial when proper screening routers are in
place- though it's certainly possible to do it if you're able to elevate
to root access. Damage already done is different than damage that can be
done again. Inside screening routers are really good for preventing
firewall-based attacks BTW.
> box and MD5 wont be finding anything. So I am confused how the first
> exploit of this type (As in gaining access to the firewall) is not
> interesting??? I just read an article over at businessweek about this
It's only interesting if you can do it. I still don't find anything
significantly interesting about either of these attacks because they were
both explicitly stopped by my *normal* installation behaviour for
Gauntlet.
I'm also not sure it's the "first exploit of this type." But perhaps the
first widely-known one.
> exploit under the BW daily section and after reading that it seems even more
> interesting.
What you find interesting and what I find interesting are different
obviously, as are our sources of technical information.
> >It looks to me like the widely available exploit code requires a
> >compromised client or malicious Web server to realize, since you can't
> >connect to the http proxy from the external network even in a default
> >install.
>
> I am not sure what code you saw, but the code over at security focus can be
> used by anyone on any remote machine. Granted that it is setup to be used
> from a Linux box, but find me one person who doesnt have linux now that has
> a clue whats going on. Not to mention its very easy to port.
Perhaps you'd like to point out how a URL with the payload can be made to
traverse the http-gw or http-pdk proxies remotely from an untrusted
network without a compromised client or malicious server unless it's via
e-mail?- which I don't know, since (a) I've never run Mattel software, and
(b) I've never used Gauntlet's smap/sendmail combo in production (lack of
trust again.) Once again, I didn't look too hard because both of these
issues were amply covered by my normal installation processes.
> >Lastly, it could be because most of us are jaded about code quality or
> >firewalling anymore.
>
> I do agree with you there. If you look at all the exploits coming out on
> security products, you can't help but feel jaded.
One of the reasons I no longer actively install and administer firewalls.
It's easier to control when the crappy code is your own.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
